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ABSTRACT 



A model is developed to simulate various aspects of Naval 
Supply Center requisition processing. The model is based on 
the Q-GERT simulation language. Q-GERT was selected because 
of the likelihood that existing stock point personnel could 
be easily trained to model stock point requisition throughput 
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basic Q-GERT concepts and develops the necessary symbology 
to model the NSC San Diego NSN requisition throughput procedure. 



4 



TABLE OF CONTENTS 



I. INTRODUCTION 8 

II. THE SIMPLIFIED MODEL 17 

III. DISCUSSION OF THE SIMPLIFIED MODEL 24 

IV. ADDITIONAL BASIC Q-GERT CONCEPTS 27 

A. THE REGULAR NODE 27 

B. BALKING AT Q-NODES 30 

C. BLOCKING SERVICE ACTIVITIES 32 

D. PROBABILISTIC BRANCHING 32 

E. Q-GERT INPUT CARD OVERVIEW 33 

V. NSC SAN DIEGO DEMAND PROCESSING DISCUSSION 35 

A. REQUISITION CATEGORIZATION 35 

B. QUICK PIC AND BEARERS (WALK-THROUGHS) 37 

C. DEMAND PROCESSING PROCEDURES 39 

D. NSC SAN DIEGO DEMAND DATA ANALYSIS 42 

E. EXCEPTIONS AND WAREHOUSE REFUSALS 46 

F. MODELING CONSIDERATIONS 49 

VI. MODELING THE ARRIVAL AND CATEGORIZATION OF 

REQUISITIONS 52 

A. ATTRIBUTE ASSIGNMENT 52 

B. CONDITIONAL BRANCHING 55 

C. THE AUTODIN ARRIVAL AND CATEGORIZATION PROCESS 57 

D. THE POE ARRIVAL AND CATEGORIZATION PROCESS 67 

VII. CUSTOMER SERVICES AND DPD KEYPUNCH 73 

A. Q-GERT RESOURCES 73 



5 



B. CUSTOMER SERVICES 81 

C. DATA PROCESSING DEPARTMENT KEYPUNCH 99 

VIII. DATA PROCESSING DEPARTMENT BATCH PROCESSING 

AND LOTTING 105 

A. DPD FUNCTIONAL OVERVIEW 10 5 

B. DPD Q-GERT SYMBOLOGY 112 

IX. ISSUE, PACKING, MARKING, AND LOCAL DELIVERY 1 20 

A. DATA CONSIDERATIONS 120 

B. BROADWAY BULK MATERIAL PROCESSING 122 

C. BROADWAY BIN MATERIAL PROCESSING 130 

D. NATIONAL CITY MATERIAL PROCESSING 145 

E. LOCAL DELIVERY 152 

F. STATISTICS COLLECTION 160 

G. POTENTIAL PROCEDURAL CHANGES 162 

X. NETWORK TIMING 165 

A. TIMING OVERVIEW 165 

B. WEEKLY MASTER AND RESOURCE INITIALIZATION 166 

C. PERSONNEL RESOURCE CONTROL 172 

D. LOCAL DELIVERY AND MESSENGER SCHEDULING 176 

E. ADP RESOURCE CONTROL AND BATCH PROCESSING 181 

F. AUTODIN AND POE ARRIVAL PATTERNS 185 

XI. SUMMARY AND CONCLUSION 195 

A. MODEL VALIDATION 195 

B. SUGGESTED AREAS OF ANALYSIS 201 

C. CONCLUSION 203 

APPENDIX A: Q-GERT DISTRIBUTION AND FUNCTION TYPES 

WITH REQUIRED PARAMETER VALUES 205 



6 



APPENDIX B: NSC SAN DIEGO DAILY DEMAND DATA - OCTOBER 

1979 THROUGH FEBRUARY 19 80 206 

APPENDIX C: DATA PROCESSING DEPARTMENT KEYPUNCH 

STATISTICS 211 

APPENDIX D: MODEL FORTRAN USER FUNCTIONS 212 

LIST OF REFERENCES 213 

INITIAL DISTRIBUTION LIST 214 



7 



I. 



INTRODUCTION 



There are many advantages associated with the maintenance 
of a capability to simulate both current and proposed operating 
procedures in a variety of settings. Models havB been developed 
to assist in the decision making process in such diverse areas 
as traffic control, war games, and for our specific purposes, 
requisition processing. Models (simulators) that closely 
approximate an existing operating system can be used confidently 
to predict the consequences of procedural changes. Models 
characterized by variables that have been shown to possess 
particular distributional qualities may have a quantifiable 
predictive value; i.e., a numeric level of confidence, or degree 
of certainty, in the predictions obtained can be calculated. 

At the very least, any reasonably representative model can be 
used to assess the relative impact of various procedural changes 
each proposed alternative is being subjected to identical model 
assumptions and the degree to which these assumptions may 
invalidate simulation output can be estimated across the con- 
templated alternatives. Most importantly, a realistic simulator 
permits an informed analysis of procedural changes without 
incurring the costs that would accrue if the system itself were 
actually modified. 

A simulation, or a computerized representation of a particu- 
lar situation, may be created in the computer language of the 
modeler’s choosing. FORTRAN, COBOL, or even Basic Assembler 
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Language could be used, albeit with a great deal of detail 
and difficulty, as the modeling mechanism. Fortunately, 
simulation languages featuring more concise coding schemes 
than standard FORTRAN have been developed to facilitate and 
enhance the modeler's efforts to obtain meaningful predictive 
results. SIMSCRIPT and GPSS are two such languages that are 
highly regarded by those familiar with their capabilities. 

A GPSS simulation of the requisition throughput process 
at NSC San Diego was developed in 1973 as an NPS (Naval Post- 
graduate School) thesis. This effort, which is specified as 
reference (b) in this study, was an exceptionally well conceived 
undertaking that possesses enormous predictive value in the 
hands of personnel schooled in GPSS. Unfortunately, Naval 
Supply Center resource constraints and workload levels generally 
prohibit the luxury of maintaining simulation specialists on 
their roles. In the absence of such expertise, not only is an 
on-site capability to expand upon the existing GPSS model missing 
but, more importantly, the modeling details used in the study 
can not be comprehended. The actual functions being performed 
by specific GPSS coding is not readily apparent. Explanatory 
data is provided either through accompany textual explanations 
or by the inclusion of comment cards at strategic locations within 
the GPSS deck. In general, except for accompanying flow charts 
and/or block diagrams, there is no recognized graphic technique 
to provide a visual display that corresponds to the GPSS (or 
SIMSCRIPT) coding in the model. 
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This project duplicates the 1973 study in the sense that 
its long range goals include the simulation of requisition 
throughput at NSC San Diego and the analysis of numerous alterna- 
tive prpcessing methods. There the similarity ends. Based on 
the premise that a picture is worth a thousand words, the NSC 
San Diego requisition processing model is developed in a rela- 
tively new simulation language called Q-GERT. Under the addi- 
tional assumption that NSC San Diego would prefer to acquire and 
maintain an on-site simulation capability, the development of 
the model becomes the vehicle for the introduction and explana- 
tion of the simulation language itself. Therefore, the basic 
dual purpose short term objective becomes the description of 
Q-GERT concepts and modeling techniques in sufficient depth to 
both familiarize stock point personnel with the language and 
provide an initial version of a model that accurately portrays 
requisition processing at NSC San Diego. 

An on-site simulator is obviously not a necessity. Intelli- 
gent decisions regarding the consequences of proposed procedural 
changes can often be made without the aid of a simulated impact 
assessment. Furthermore, if a detailed familiarity with the 
simulator is considered either nonessential or inadvisable in 
view of the demands on existing personnel, simulations can be 
conducted by external sources; e.g., the GPSS model could be 
updated and used to model alternatives selected by NSC San Diego. 
There is, however, no guarantee that adequate external resources 
will be available when needed. Furthermore, there is always a 
possibility that the alternatives modeled may differ to some 
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degree from those specified by NSC San Diego. Finally, as 
explained below, model formulation useing Q-GERT begins by 
developing structured network symbology from which the trans- 
lation to the simulation cards is directly accomplished. There- 
fore, the maintenance of an on-site Q-GERT simulator equates 
to the existence of a current graphic representation of the 
requisition processing system. The first step in evaluating 
any proposed change is to revise the graphics of the affected 
network segment. Therefore, the revised network symbology h s 
already been completed if the change is subsequently incorporated 
into the system. 

There are both training and data processing costs associated 
with simulating on-site. Personnel must be trained in the Q-GERT 
symbology and input card development. This study describes a 
majority of the network graphics and their purpose. The reference 
(a) text by A. Alan B. Pritsker, the developer of Q-GERT, pro- 
vides a field-by-field description of each required card type. 

There are basically two approaches that can be taken to ac- 
quire a Q-GERT data processing capability. The language may 
be purchased from Pritsker and Associates and loaded locally on 
disk or some other peripheral device. There may be significant 
problems encountered with this approach if the intent is to 
use existing Burroughs equipment. First, the Q-GERT language 
is coded in ANSI FORTRAN, which can not be directly compiled 
by Burroughs equipment. The differences in the Burroughs ver- 
sion of FORTRAN are not major, but some conversion would be 
needed. Secondly, the core requirement to load the 1,000 node 
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version of Q-GERT will be large, NPS personnel can provide 
information on core requirements and run times for the smaller 
100 node version. Pritsker and Associates, whose address and 
telephone number are included in the Distribution List, may be 
able to address, or even refute, the Burroughs incompatibility 
problem. They, of course, are the only source for pricing 
information on the cost of acquiring, and perhaps installing, 
the 1,000 node version of Q-GERT. It should be noted that the 
purchase and installation of Q-GERT at a local activity having 
IBM equipment, if there is such an activity, is a feasible 
alternative. Programs could be submitted either through card 
or remote input and the FORTRAN compatibility problem would be 
avoided . 

The second approach for acquiring a Q-GERT capability con- 
sists of obtaining remote access to an activity that has already 
purchased the language. NPS is such an activity and, although 
only the 100 node version is currently operational, the necessary 
1,000 node capability will be established in the near future. 

NPS can provide the details and costs associated with the remote 
access approach. It suffices to note that the initial model, 
or revised versions, would be maintained on NPS disks, accessed 
through a telephone remote, and activated by means of a standard 
password procedure. 

The main advantage of an on-site simulation capability is 
the flexibility it provides in the analysis of proposed system 
changes ranging from the reallocation of existing resources to 
the addition of completely new functional areas. As Chapters 1 



12 



through 10 are reviewed, knowledgeable NSC San Diego will iden- 
tify numerous additional alternatives that could be evaluated; 
the very process of tracing transaction flow through the model 
creates speculation about the impact of doing things differ- 
ently. The Q-GERT concept of graphically displaying the model 
contributes to a better understanding of the system being modeled 
and facilitates the identification of processing alternatives. 

It is not difficult to imagine the system graphics serving as 
a training device for Management Analysts and Planning Depart- 
ment personnel . 

NSC San Diego is requested to assess the potential of the 
model developed for on-site use and advise Professor F. R. 
Richards of NPS , autovon 87 8-2543, of their findings. If the 
aforementioned costs, which are quantifiable, are considered 
prohibitive regardless of the potential benefits, then a recom- 
mendation of no further effort in this area is appropriate. A 
management review of the model development chapters may still 
be useful? processing procedures must necessarily be described 
during the detailed discussion of the model and alternatives 
to some current operating practices have been presented. 

If model validation and actual simulation runs are considered 
paramount for the NSC San Diego decision, funding for a second 
thesis effort when the 1,000 node model is operational will 
probably be necessary. If the capability is unequivocably de- 
sired, the funding of a second thesis project would still appear 
to contribute to an orderly implementation process. The stu- 
dent, a Supply Corps officer familiar with both Q-GERT and 
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stock point operations, would be available for consultation 
on-site regarding model validity, possible revisions, and the 
identification of processing alternatives to be tested. With 
the 1,000 node model and the initial Q-GERT card deck at his 
disposal at NPS, the student could verify (debug) the model 
prior to arrival at NSC San Diego. 

In grand design, an expanded version of this model could 
develop into a stock point simulator. The existence of a revi- 
sion representing each major stock point can realistically be 
envisioned. However, if the enclosed humble beginning is ever 
perceived as evolving and expanding to that degree, a few pre- 
liminary cautions should be heeded. As detailed as the figures 
in Chapters 6-10 may appear, this model version may be viewed as 
sacrificing efficiency for the sake of illustrative symbology. 
Consequently, some ratlrer cumbersome adaptations of basic Q-GERT 
concepts were used in place of more efficient programming methods; 
e.g., the messenger service modeling approach described in Chap- 
ter 6. The efficiency can be improved through the development 
of FORTRAN program segments to replace the more inefficient seg- 
ments of the model. The use of such program inserts, which 
serve to provide Q-GERT a practically unlimited modeling capa- 
bility, was deliberately avoided in this study; FORTRAN insert 
functions cannot be described using standard Q-GERT symbology 
and their use obscures the graphic details associated with that 
segment of transaction processing. Simply stated, the objective 
was to provide detailed graphics and guidance on Q-GERT, not 
FORTRAN. Based on the review of this study by Pritsker and 
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Associates, it may be recommended that any universal acceptance 
and subsequent development of a stock point simulator concept 
be accompanied by a switch to a simulation language called 
, SLAM, which can be categorized as a combination of Q-GERT and 
SIMSCRIPT. Regardless of the approach ultimately taken to 
improve model efficiency, this simplistic initial version re- 
mains a logical starting point. 

The model was designed to accommodate expansion when, or 
if, such an action becomes desirable. Areas where expansion 
might be considered are mentioned throughout Chapters 6 through 
IQ. Chapters 2 through 4 describe an extremely simplified re- 
quisitioning processing system and introduce the Q-GERT concepts 
and symbology needed to model that system. Additional Q-GERT 
concepts that will be used in later chapters are also covered 
in detail. 

Chapter 5 contains an extremely detailed discussion of re- 
quisition processing at NSC San Diego. Requisition categoriza- 
tion and processing specifics for each category, demand excep- 
tion workload and processing, POE and autodin demand data, and 
the scheduling of demand processing runs are among the topics 
presented . 

Chapters 6 through 10 introduce additional Q-GERT concepts 
as they are used, provide the graphic representation of a par- 
ticular functional area or process such as autodin arrivals, and 
give a detailed description of transaction flow through the 
network segment. Chapters 6 through 9 cover the basic model 
from requisition arrival and categorization (Chapter 6) to the 
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movement of material from local delivery or to shipping (Chap- 
ter 9) . Chapter 10 is devoted entirely to the timing of resource 
availability (personnel, ADP, messenger, etc.) and the shifting 
of daily demand patterns . 

Chapter 11 delineates modeling techniques that should be 
closely reviewed during the verification process, suggests 
alternative requisition processing schemes that could be evalu- 
ated in a subsequent thesis effort, if forthcoming, and provides 
concluding comments that include a sincere statement of grati- 
tude to the many NSC San Diego employees who were most unselfish 
with both their time and assistance. 

It is regrettable that time constraints and the nonavaila- 
bility of the larger (1,000 node) Q-GERT version combined to 
preclude either full model or segmented simulation runs. Sam- 
ples of standard Q-GERT output, which was the only statistical 
data programmed in the initial version, may be obtained from 
either NPS or, one would assume, from Pritsker and Associates. 
Reference (a) , Modeling and Analysis Using Q-GERT Networks, 
contains numerous and excellent examples with accompanying 
illustrations of standard Q-GERT output. A segmented approach 
to running the model, which contains over 400 nodes, posed the 
problem of defining a segment of less than 100 nodes that could 
be meamingfully interpreted. Since developing such a model 
involved extraction of segments from all chapters, the ultimate 
requirement was the development of a completely new model, a 
process that simply could not be accomplished in the limited 
time remaining. 
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II. THE SIMPLIFIED MODEL 



Figure 2-1 depicts an extremely simplified version of the 
requisition processing procedure. It represents the basic 
functions that must be performed at any stock point to process 
a customer request and effect the subsequent issue of the 
required material. Inherent in the procedure illustrated are 
numerous assumptions that are initially made to facilitate 
introduction of basic Q-GERT symbology at the least detailed 
level possible. 
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Figure 2-1. Simplified Requisition Processing Model 



First, it is hypothesized that each requisition is processed 
in an identical manner; i.e., there is initially no priority 
scheme that distinguishes one request from another and each 
requisition must be processed by all system components. 

Secondly, it is initially assumed that each request results 
in an issue. Gone for the time being are such minor annoyances 
as editing and keypunch errors, nonavailability of material 
whether NIS (Not in Stock) or NC (Not Carried) , demand processing 
exceptions, and warehouse refusals. However, these and other 
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actual processing techniques that are more representative 
of actual system operation will beintroduced as the Q-GERT 
model is expanded to incorporate system complexities. 

Figure 2-2 represents the Q-GERT symbology corresponding 
to the basic system described above. This system will be 
discussed at a level of detail sufficient to serve as the 
mechanism for the introduction of basic Q-GERT concepts as 
described in Chapter 2 of reference (a) . 
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Figure 2-2. The Q-GERT Simplified Model 



Inasmuch as this graphical representation contains a series 
of slightly dissimilar nodes connected by branches it will 
henceforth be designated a Q-GERT network. The nodes are iden- 
tified by the number in the far right partition. Node function 
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varies by type and each node illustrated is discussed in de- 
tail below. Network activities - editing, keypunch, etc., - 
are performed on the branches of the network and are identified 
by the number in the box under the branch; e.g., the designation 
2 represents the edit activity of function. Branches generally 
represent the passage of time, or service time, in the network. 
When specified, the circled number beside the activity number 
beneath the branch indicates the number of identical servers 
available to perform the required activity. 

Transactions, in this case requisitions, flow through the 
network and are serviced on the network branches. Node 1, the 
source node, functions as a demand generator and will be dis- 
cussed later. It suffices to note that the arriving transac- 
tions/demands are initially processed at the editing station 
represented by activity 2. Since there are only three (3) 
servers available to perform the edit function, it is likely 
that the requisitions will have to await service. Hence the 
insertion of node 2, a queue node (Q-node) , between the source 
node and the edit activity. In fact, service activities are 
always preceeded by Q-nodes and, for the time being, only by 
Q-nodes . 

A description of the partitions in queue node 2 is provided 
in Figure 2-3. Note that the remaining Q-nodes in this simpli- 
fied network, nodes 3 through 8, are identical except for the 
node number associated with each. All are initialized with 
zero transactions/demands awaiting service and there is no 
limit on the number of transactions that can accumulate at each 
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Figure 2-3. The Q-Node 



queue. Finally, since the requisitions are indistinguishable 
by assumption, they are simply processed sequentially, or first- 
in-first-out as indicated by the F in the center partition. 

Other ranking possibilities and techniques will be discussed 
later. However, it should be emphasized at this time that Q- 
nodes preceed service activities and the ranking of transac- 
tions (demands) is accomplished solely to designate which item 
will be processed by the next available server from the activity 
immediately following the Q-node. 

Figure 2-4 provides a similar overview of the source node, 
node 1, partitions. Designation of the upper middle partition 
is deliberately omitted. Alternatives to the M specification 
in the lower middle portion will be introduced later. Since 
the node illustrated is a source node, the M designation is 
basically redundant. Each transaction generated at a source 
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Figure 2-4 . The Source Node 



node is automatically assigned a mark time representing the 
transaction time of origin. Unless subsequently altered, this 
mark time will accompany the transaction through the network 
and is defined as a transaction attribute. Note that there 
are two branches emanating from the source node. With only 
one transaction required to release this node as indicated in 
the bottom left partition, each nodal release will result in 
identical transactions being routed along both the branch/activity 
labeled 13 and the activity labeled 1. This node serves as an 
example of the deterministic branching process in Q-GERT . The 
transaction could have been routed along numerous other branches. 
When deterministic branching is used, the release of a node 
leads to the routing of an identical transaction on each branch. 
Note that there are no server designations on either of the 
branches from the source node. Since this node is not a 
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Q-node, the activity following it can not be a service 
activity . 

It has been noted that network branches represent the 
passage of time. The notation (EX,1) above the activity 1 
designator represents the specified method for computing the 
delay between releases of node 1. This delay represents the 
time between arrival of demands and (EX, 1) indicates that the 
delay will be taken from an exponential distribution with 
parameters defined in parameter set one. The Q-GERT input cards 
will contain both an ACT card to describe activity 1 and a PAR 
card providing the required parameter values for an exponential 
distribution. Numerous distributions are available to model 
activity times. Appendix A lists those discussed in reference 
(a) . Note on Figure 2-2 that activities 4 and 5 feature normally 
distributed service times with parameter set numbers 2 and 3 
providing the appropriate distributional information. Activi- 
ties 6 and 8 exhibit service times from a uniform distribution 
described in the indicated parameter sets. However, the speci- 
fication CO for activities 2, 3, and 7 represents a constant 
function and the number following CO is the number of time units 
required to perform the activity. Finally, activity 13 between 
nodes 1 and 2 indicates both that activity numbering need not 
be sequential and that a branch need not represent the passage 
of time. The absence of an activity time designation consti- 
tutes a (CO,0) distributional assumption or a zero passage of 
time. Therefore, the requisition arrival time corresponds to 
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entry into the edit queue in the Q-GERT simplified model depicted 
in Figure 2-2. 

Node 9 in Figure 2-2 need not be labeled here. The I in 
the bottom middle partition indicates that interval statistics 
are to be collected; i.e., the difference between the time of 
arrival at node 9 and the time of origin at node 1. Otherwise 
each partition is defined exactly like the source node illus- 
trated in Figure 2-4. The initial and each subsequent arrival 
of a transaction, the material necessary to satisfy a demand, 
will release node 9 and prompt the collection of interval sta- 
tistics representing that requisition's time in the system. 

The inclusion of the symbol — 'vw^ on the right side of node 9 
serves to designate it as a sink node. If the symbol were 
omitted and the transaction routed elsewhere, this node would 
be categorized as a statistics node. A sink node can be viewed 
as the mechanism by which a completed transaction departs the 
network. Q-GERT simulation runs are often terminated on the 
basis of a specified number of sink node releases. 
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III. DISCUSSION OF THE SIMPLIFIED MODEL 



An intuitive appraisal of the Figure 2-2 simplified model 
leads to the conclusion that it does not represent a particu- 
larly challenging problem. Simulation runs would lead to the 
automatic generation of relevant Q-node and service activity 
statistics by the Q-GERT Analysis Program. These statistics 
include average number of transactions in each queue and server 
utilization data. Therefore, assuming activity and arrival 
distributional assumptions are correct, the simulations would 
be most useful for identifying potential backlog problems and 
excess or inadequate resources at each service activity. If 
the servers could be used at any activity within the network , 
the simulation runs could be used to generate the "best" possi- 
ble allocation of resources within specified constraints. 
Nevertheless, the simplified model is useful as a basis for 
the introduction of Q-GERT symbology and as a point of departure 
for modeling the NSC San Diego requisition processing procedure. 

The number of servers assigned to each Figure 2-2 activity 
and the specified service time distributions are strictly hypo- 
thetical and used only for Q-GERT illustrative purposes. As 
the NSC San Diego model is developed, the service times assigned 
will generally be identical to those used in reference (b) , which 
were based on the DIxMES (Defense Integrated Management Engineer- 
ing Systems) study specified in reference (c) and conducted in 
1968. Departures from the use of these standards, which are of 



24 



dubious validity if only due to technical innovations in the 
last 12 years, will be noted during the model development. It 
should be emphasized at this point that the usefulness of any 
Q-GERT model is directly related to the validity of the service 
time assumptions which, if correctly established, emanate from 
a series of time and motion studies that provide a represen- 
tative sample of service times as an input to curve fitting 
tests. This procedure enables the modeler to express a degree 
of confidence in his results rather than placing the validity 
of his model at the mercy of the distributional assumptions. 
Unfortunately, the latter undesirable situation happens to be 
the case in this model. Time constraints precluded the develop- 
ment of current standards for each service activity. Fortunately, 
however, more accurate standards can easily be incorporated into 
the existing model. The activity card and, if necessary, the 
accompanying parameter card corresponding to this service activity 
must be changed to correspond to the new service time distribution 
annotated on the revised branch. 

As a final comment on Figure 2-2, the function performed 
by activity 4, records update and issue document preparation, 
is basically a mechanized function performed by the computer 
CPU (Central Processing Unit) in conjunction with appropriate 
peripheral equipment. In the simple model this process can 
be visualized either as a completely manual or partially auto- 
mated activity. How it is done is basically irrelevant; the 
important factor is the validity of the assumption regarding 
how long it takes to perform the function. 
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This concludes the discussion of the simplified model 
featuring sequential requisition processing through a series 
of service activities with all transactions (requisitions/ 
demands) being satisfied. Perhaps such a model would be appro- 
priate for a company such as a discount stereo distributor who 
begins each day with a zero backlog (initial number of transac- 
tions in each queue is zero) , receives telephone orders for a 
specified time period each day, always satisfies each order 
through various local sources, and closes when all orders have 
been staged for delivery. As illustrated, however, the Figure 
2-2 model wouldn't provide an accurate assessment of the stereo 
distribution process because it lacks a timing mechanism to 
terminate the arrival of transactions (orders) while permitting 
existing orders to be fully processed. Q-GERT timing logic 
will be introduced in the course of the model development that 
follows. However, before beginning to develop the NSC San Diego 
processing procedures, some additional basic Q-GERT concepts 
must be presented. 
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IV . ADDITIONAL BASIC Q-GERT CONCEPTS 



A. THE REGULAR NODE 

Figure 4-1 depicts the most common Q-GERT node, the regular 
node. In general, the regular node functions to route trans- 
actions and assign attributes as discussed later during the 
model development. 



Number of transactions 
necessary for initial release 



Number of 
transactions 
necessary for 
subsequent 
releases 




Choice criterion used 
when transactions are 
accumulated prior to node 
release. Specifies which trans- 
action's attributes are routed 
upon node release. 

— Node number 



Blank for a regular 
node. Insertion of statistics 
gathering specification makes 
the node a statistics node 



Figure 4-1. The Regular Node 

The use of the middle partitions will be discussed below when 
the accumulation of transactions is addressed. These parti- 
tions deal with a decision-making process based on attribute 
values which will be introduced later. The only attribute 
encountered thus far is the automatically assigned mark time 
designator. When not used to assign attributes or accumulate 
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transactions, the regular node usually appears in the simple 
form illustrated in Figure 4-2. 



For initial 
release 




■Node number 



For 



Subsequent 

releases 



Figure 4-2. The Simple Regular Node 



Note that the value 1 for initial and subsequent release indi- 
cates that no accumulation of transactions is taking place. 
Therefore, there is no requirement for a center partition. The 
converse is not true, however. Values other than 1 could be 
assigned to the initial and subsequent release partitions with 
no center partition defined. In that case, the default values 
for the center partitions shown in Figure 4-1 will be assigned. 

The regular node functioning as a transaction accumulator 
is illustrated in Figure 4-3. It may appear in either of the 
forms indicated. 




M could be used vice x 



number 



IBlank if Regular Node 

Coding for specified statistic would make it a 
Statistics Node 



Figure 4-3. Regular Node as a Transaction Accumulator 
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The partitions are defined on Figures 4-1 and 4-2. The value 
of 2 for initial and subsequent nodal release is an example 
only. The possible values for the upper middle partition are 
shown and represent First, Last, Smallest, and Biggest, respec- 
tively. This accumulator function serves to eliminate trans- 
actions in the network. The required accumulation of input 
transactions leads to the release of only one transaction. 
Therefore, since each transaction possesses at least one attri- 
bute, the mark time, and often more than one, it is necessary 
to designate which transaction's attributes will be routed when 
the node is released. An F designation specifies "route the 
first transaction's attributes"; similarly, the L indicates 
the last transaction's attributes should be routed. However, 
when B or S is used in the upper segment, the indicated /x 
symbol should accompany it since x designates the relevant 
attribute. Therefore, B or S indicates that the attributes 
of the transaction having the Biggest or Smallest value of 
attribute x should be routed. For example, the dollar value 
of a requisition may be assigned as an attribute of that trans- 
action. Then the requisition having the highest dollar value 
could be selected from an accumulation of demands. Note that 
an M may be used instead of an integer x. The M represents 
the mark time of the transaction. In the absence of a center 
partition, the attributes associated with the last arriving 
transaction are routed. The accumulation function was introduced 
to illustrate the diversity of Q-GERT. Since each requisition 
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must be processed in the NSC San Diego model, accumulation 
of transactions will not play a direct role in subsequent 
model development. 

B. BALKING AT Q-NODES 

Q-nodes will now be revisited to illustrate the concepts 
of balking and blocking. Figure 4-4 is a labeled Q-node and 
is similar to the Q-node specified in Figure 2-3. 



Initial 
number 
in queue 

Maximum 
number in 
queue 




Procedure for ranking transactions 
in the queue 

Node number 



Q-Node indicator 



Figure 4-4. The Q-Node Revisited 

Recall that a service activity follows a Q-node; in this case, 
service activity 2 featuring 3 servers is indicated. If an 
initial number in the queue other than zero is specified, Q- 
GERT assumes that all servers are busy and schedules service 
time completions accordingly. Therefore, placing a 2 in the 
initial number section of Q-node 2 indicates there are 5 trans- 
actions in the system; i.e., 2 awaiting service and 3 being 
serviced by the servers in activity 2. 

The queue capacities illustrated thus far have been infinite. 
Suppose Q-node 2 above has a maximum queue capacity of 6. 

Further assume that the queue is "full" and a seventh transaction 
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arrives. This additional transaction can not be accommodated 
at Q-node 2. Therefore, Q-GERT permits the modeling of trans- 
action balking as illustrated in Figure 4-5 or, if appropriate, 
blocking of the service activity preceding Q-node 2 (Figure 4-6) . 



Sink Node 




IAJ 



Figure 4-5. Balking 

The balking situation illustrated on the left of Figure 4-5 pro- 
vides for the return of the transaction to the Q-node after one 
time unit (C0,1) until the transaction is accepted. The dot- 
dash line represents a balking action which would be described 
on the Q-GERT card corresponding to Q-node 2. Therefore, there 
will be no activity card describing the dot-dash branch from 
Q-node 2 to regular node 3. In fact, nonsolid branches, and 
others will be encountered, are not considered activities by 
Q-GERT. The balking scenario depicted on the right side of 
Figure 4-5 depicts a transaction being balked out of the net- 
work while having interval statistics maintained at the sink 
node. 
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C. BLOCKING SERVICE ACTIVITIES 



Figure 4-6 illustrates the phenomena of blocking that can 
occur when a service activity output is routed to a Q-node with 
a finite queue capacity. 



This situation occurs when Q-node 2 is at its capacity and 
the servers at activity 1 can not proceed until the transaction 
just completed can be transferred to the Q-node for activity 2, 
Specifically, blocking occurs if at least one of the two servers 
at activity 1 has completed an activity but can not begin to 
process another transaction from the Q-node (not shown) pre- 
ceding activity 1 due to the inability of Q-node 2 to accept 
another transaction. If the blocking function is included in 
a model, it will be indicated on the Q-GERT card describing 
Q-node 2. 

D. PROBABILISTIC BRANCHING 

Thus far all branches leaving the nodes described were 
deterministic. That is, each release of the node resulted in 
the transaction (s) released being routed along each branch. 

Prior to commencing the model formulation, probabilistic branching 
must be addressed. Figure 4-7 illustrates probabilistic 
branching from a regular node. 




(NO, 3) 




Figure 4-6. Blocking 
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Figure 4-7. Probabilistic Branching 
A transaction leaving node 1 will take branch/activity 6 with 
a probability of 0.8 and will encounter a constant 2 time unit 
delay while traversing that branch. Conversely, activity 7 
with its constant 5 time unit delay will be undertaken with 
probability 0.2. Therefore, a transaction leaving node 1 will 
take one branch or the other, but never both as in deterministic 
branching. The symbol on the right side of regular node 

one contains the node number and indicates that probabilistic 
branching applies. Naturally, the sum of the probabilities on 
the branches leaving the node must equal 1. Both probabilistic 
and conditional branching, which will be introduced when used, 
will often be encountered in the NSC San Diego model. 

E. Q-GERT INPUT CARD OVERVIEW 

Finally, some additional comment on the cards required to 
actually conduct an analysis of a Q-GERT network is required. 
Perhaps the most impressive feature of Q-GERT is that the vast 
majority of the input cards are created directly from the 
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graphical representation of the network. In general, there 
is a card corresponding to each node, each activity, and each 
parameter set referenced to describe an activity duration. 

This series of cards plus a GEN card to provide initializing 
data and simulation termination rules and a FIN card to signal 
the end of the data describing the network are all that are 
needed to effect a simulation of basic Q-GERT networks. Although 
the situation becomes more complex as subnetworks are added, 
reference (a) provides excellent formats describing the fields 
of all required input cards. Therefore, a detailed description 
of input card development will not be included. 
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V. NSC SAN DIEGO DEMAND PROCESSING DISCUSSION 



A. REQUISITION CATEGORIZATION 

NSC San Diego customer demand can be divided into the two 
major categories of autodin and POE (Point of Entry) . Auto- 
din requisitions are further subdivided into IPG (Issue Pri- 
ority Group) I, II, and III requests since response time 
standards established by reference (d) necessitate different 
processing methods for each category. POE requisitions are 
also processed according to IPG. However, further subdivisions 
within each IPG must be considered if the model is to resemble 
reality. For example, POE IPG I requisitions can either be 
"Bearers" (Walk-Throughs) or be unaccompanied such as a message 
requisition. POE IPG II transactions may be QUICK PIC, un- 
accompanied, or, to a limited degree, special program requests. 
Finally, POE IPG III transactions may be subdivided into re- 
quests for provisions, special program requirements, SERVMART 
replenishments, and the largest subcategory designated "OTHER". 
Each group is processed differently. Table 5-1 provides a 
brief description of the processing method for each. 
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There is a tertiary subdivision of selected POE categories 
that is implied in the processing overviews in the table. 

Namely, if the requisitioner has a mechanized system such as 
SUADPS (Shipboard Uniform Automated Data Processing System) , 
then the keypunching function need not be performed at the 
Supply Center. The mechanization distinction must be made for 
all POE secondary subdivisions except Special Programs, SERVMART, 
and dry provisions. Although the number of mechanized customers 
is a function of ship operating schedules and will vary con- 
siderably, it is estimated that 25-33% of all POE requisitions 
submitted to NSC San Diego are in a mechanized format. As a 
final comment on Table 5-1, it must be emphasized that deviations 
from the strict categorization portrayed do exist. For example, 
IPG II CASREPTs can and do quality as Bearer requisitions. 
Nevertheless, only the categories specified and the mechaniza- 
tion feature will be used to identify requisition types in the 
model . 

B. QUICK PIC AND BEARERS (WALK-THROUGHS) 

The data base used for the Appendix B demand calculations 
was October 1979 through February 1980. This period was chosen 
to correspond to the advent of the QUICK PIC program. Prior 
to October 1979, NSC San Diego permitted walk-throughs (Bearers) 
on both IPG I and II requisitions. Each walk-through represented 
an interruption to normal processing and a detrimental impact 
on the response time associated with the issues that were sub- 
sequently delayed. Therefore, except in the case of IPG II 



37 



CASREPTs , special project codes, and designated types of mate- 
rial such as gas cylinders, walk-throughs were restricted to 
IPG I requisitions and QUICK PIC was established to provide an 
expedited response system for IPG IIs that heretofore had been 
submitted as Bearers. Requisitions left at designated drop 
points are picked up by an NSC driver, processed and sorted 
in a special run, picked/issued first on the next working day, 
and staged at National City for customer pickup at 1400. There- * 
for, a one working day turnaround time applies. The program 
appears to be working extremely well. The average daily number 
of Bearers, and thus the number of routine processing inter- 
rupts, have greatly decreased. Table 5-2 shows the Bearer 
average for each day of the week and the percentage of that day’s 
POE IPG I input that the average represents. 



DAY OF 
WEEK 


BEARER 

AVG 


STD DEVIATION 
OF BEARER AVG 


BEARER AVG % OF POE 
IPG I DAILY AVG 
FROM APPENDIX B 


SAT-MONDAY 


134 


75.6 


66% 


TUESDAY 


83 


20.5 


45% 


WEDNESDAY 


76 


27.7 


50% 


THURSDAY 


85 


31.5 


56% 


FRIDAY 


98 


35.3 


54% 



Table 5-2. Bearer Statistics 

Using column 4 of Table 5-2, the average Bearer percentage of 
POE IPG Is across the week then computes to 54.2% with a 
standard deviation of 7.8%. 
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The reference (e) Customer Service Feeder Reports do not 
provide a QUICK PIC count although the value has been included 
in the Hot Line IPG II daily total. However, available reports 
do indicate a QUICK PIC average issue quantity of 110 per day. 
Since it can only be assumed that QUICK PIC faces the same proba- 
bility of availability as other IPG II requisitions, the average 
daily number of QUICK PIC requisitions is projected at 162 per 
day based on a 68% gross availability rate. 

C. DEMAND PROCESSING PROCEDURES 

As used in this study, demand processing refers to the 
function of checking an item's on-hand asset position and taking 
one of the following three actions: 

. Committing available assets to satisfy a requisition 

Placing a requisition "in-process" based upon the current 
availability of assets with no commitment/reduction of on-hand 
assets at that time 

. Referring the transaction based on nonavailability of 
assets. Special advice codes such as "Fill or Kill" that serve 
to eliminate the referral will be ignored for the purposes of 
this report. 

The demand processing procedure is performed by two UADPS-SP 
(Uniform Automated Data Processing System - Stock Point) pro- 
grams. Both versions will refer transactions at the time of 
processing based on nonavailability of assets. The on-line 
version is activated by transaction/requisition input from 
remote terminals and may be used to either commit assets and 
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receive a corresponding issue document for immediate processing 
or place transactions in-process. The second program is used 
to perform batch demand processing. It is run periodically 
throughout the day and results in either a commitment of 
assets or a referral (partial issues are ignored) for each 
requisition processed. The batch processing mode, as currently 
used, can be viewed as a procedure for placing issue document 
images on tape for further processing if assets were available. 

All IPG I requisitions, both autodin and POE, are input 
via remote terminals and either processed to completion or 
referred. Autodin IPG II and III requisitions are received on 
tape six times a day and batch processed each time. The first 
batch run is scheduled for 0330 and the last at 2200. There- 
fore, autodin IPG II and III processing can be viewed as both 
a generator of referrals based on the gross availability at the 
time of batch processing and an originator of six tapes contain- 
ing issue document images that will undergo additional processing. 

There are three additional batch processing runs daily. 

QUICK PIC requisitions are batched separately at 0100 and all 
Provisions requests are processed at 1800 daily. These cate- 
gories are neither delayed by the Production Planning routine 
nor subjected to the standard lotting process; they are simply 
sorted by location and issued the next working day. The final 
batch run serves as a supplement to the six autodin runs already 
mentioned. It must be noted that while the autodin runs are 
scheduled to accommodate the IPG II and III autodin input, any 
available POE input will also be batch processed during the six 
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runs. Therefore , all POE input except Provisions and QUICK 
PIC will be processed during one of the seven aforementioned 
batch runs. Of course, nonmechanized input can not be batch 
processed until it has been keypunched as described in Chapter 
7. 



The astute reader will recognize that all the Table 5-1 
categories have now been addressed except for the POE IPG II 
requests from nonmechanized customers. This category of trans- 
action is put in-process from remote terminals during the course 
of the day and no assets are reserved/committed for these demands 
until approximately 1800 when the UADPS-SP program that releases 
in-process issues generates another tape containing issue docu- 
ment images. To illustrate the consequences of this procedure, 
it must be noted that batch processing, which commits assets, 
may allocate material to a lower priority requisition if the 
batch run is conducted after the POE IPG II is put in-process 
but before its 1800 release. Secondly, POE IPG IIs put in- 
process after 1800 by the Customer Service second shift are 
necessarily delayed approximately 24 hours and subjected to 
another series of batch runs that may commit available assets. 

This factor becomes particularly relevant when it is realized 
that placing POE IPG II requisitions in-process is of secondary 
importance with respect to processing autodin and POE IPG I 
transactions. Therefore, it may reasonably be assumed that many 
of these in-process actions are initiated on the second shift 
and, at least potentially, accomplished after 1800. In recognition 
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of these possible adverse consequences, a rescheduling of the 
in-process release program to a later time (nearer to 2400) 
is being considered. In addition, discussions currently being 
held will probably lead to revised demand processing batch 
procedures that will function to place some, and possibly all, 
IPG III demands in-process where, when released, they will be 
issued after IPG IIs. 

The information provided thus far in this chapter has been 
presented to emphasize the complexity of requisition processing 
procedures and provide the rationale for numerous features 
that will be incorporated into the model. Prior to proceeding 
with a discussion of the NSC demand data contained in Appendix 
B, it is imperative to realize that the various tapes contain- 
ing issue document images are all run through appropriate local 
Production Planning/sorting/lotting programs beginning at 
approximately 0300. The relevance of this factor is that the 
issue documents associated with transactions that were either 
batch processed or released from in-process are not delivered 
to the appropriate warehouse until, at the earliest, 0730 the 
next working day. 

D. NSC SAN DIEGO DEMAND DATA ANALYSIS 

Appendix B contains daily requisition frequency averages 
for the five month period encompassing October 1979 through 
February 1980. As previously mentioned, the beginning of this 
period corresponds to the commencement of the QUICK PIC pro- 
gram. Daily averages were computed from the reference (e) 
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reports and include IPG I , II, and III averages within both 
the autodin and POE categories. Provisions requisitions are 
listed as a separate POE category and are considered IPG III 
requests despite the existence of occasional IPG II demands. 

The data was displayed in the Appendix B format to determine 
whether similar IPG percentages applied to autodin and POE re- 
quests. The data illustrates that the IPG I percentage ranged 
from 14.5% to 21.2% for autodin transactions and from 4.. 7% to 
6.5% for POE demands. This significant difference effectively 
ruled out any assumption that IPG percentages were consistent 
for both major transaction categories. That factor and, per- 
haps more importantly, the extended portion of the day for 
which autodin arrivals occur led to the decision to model the 
arrivals separately. Therefore, Chapter 6 describes distinct 
arrival and transaction categorization processes for each type. 

A cursory review of Appendix B indicates an excessive amount 
of variability in the category averages. In fact, had the 
replacements indicated in the appendix footnotes not been made, 
the applicable standard deviations would have been even higher. 

In view of the nature of the data, the time between arrivals 
will be assumed to be uniformly distributed for both autodin 
and POE source networks. Some consideration was given to defining 
gamma distribution parameters that would more accurately reflect 
the interarrival times implied by the Appendix B demand data. 
However, the lack of any definitive information relating input 
levels to time of day made this approach significantly less 
attractive. If a more detailed analysis of the requisition 
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arrival process is conducted in the future, the model may 
easily be modified through the replacement of the existing 
ACT (activity) and PAR (parameter) input cards described in 
Chapter 6. 

Since a uniform time between arrivals implies that each 
duration within a specified interval is equally likely, the 
maximum and minimum durations are the only values specified 
by Appendix A as necessary to define a UN (uniform) parameter 
set. Using Thursday demand data from Appendix B and assuming 
arrivals may occur over a 24 hour period, the uniform dis- 
tribution parameter set (max and min) will be computed for 
autodin arrivals in the following manner: 

. An IPG percentage weighted standard deviation will be 
computed using the formula 

l - - x s. Deviation IPG i. 

i=l 1UU 

The computation for Thursday is given by 

(.168x120.62) + (.428x445.37) + (.404x243.27) = 309 . 

This calculation can be considered to represent an expected 
standard deviation across all IPGs. 

. The maximum and minimum time between arrivals will then 
be calculated as the times associated with the arrival of a 
requisition quantity two weighted standard deviations lower 
and higher than the daily average. The maximum time between 
arrivals would occur when the number of arrivals was two weighted 
standard deviations below the average; i.e., 1829 - 618 = 1211 
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arrivals which implies a 0.0198 hour (24 f 1211) maximum. The 
minimum is given by 24 f (1829 +618) = 0.0098. 

The parameter set describing the POE arrivals may be defined 
in a similar, but slightly more complex, manner. An expected 
standard deviation across all Hot Line IPGs would be computed 
as 



(. 06 x 76.47) + (.615 x 763.77) + (. 325 x 339.9) = 585 

for Thursday's data. Adding two standard deviations (1,170) 
to the Hot Line daily average of 2,551 yields 3,721 as the num- 
ber of requisitions corresponding to the minimum value of the 
uniform interval describing Hot Line arrivals. Likewise, sub- 
tracting 1,170 indicates that 1,381 demands define the maximum 
interval point. However, a Hot Line interval does not account 
for all POE input; Special Program, provisions, and SERVMART 
requests are not included for the following reasons: 

. The reference (e) reports generally allotted the same 
number of demands for provisions to each day of a given week/ 
reporting period. This occurred because weekly, vice daily, 
provisions counts were provided. 

. Special Program demand submission patterns were necessarily 
very sporadic due primarily to the accumulation of requests for 
specific programs. The existence of numerous "zero transaction" 
days and widely fluctuating quantities made it prudent to simply 
compute a daily average of 107 IPG II requests and 590 IPG III. 

. The only SERVMART replenishment count data that was 
readily available was a 255/day average. 



45 



To account for these three special categories, which will 
immediately be extracted and separately identified in the 
model, the minimum and maximum POE endpoints described above 
must be shifted. Therefore, the sum of the daily averages for 
Special Program, SERVMART, and provisions (specified by day) 
requests must be added to both sides of the interval. Thurs- 
day's uniform demand interval will then be defined in the 
following manner: [1,381 + (107 + 590 + 255 + 550), 3721 + 

(107 + 590 + 255 + 550)] or [2,883, 5,223]. Finally, the time 
between arrivals associated with the appropriate requisition 
quantity is calculated by dividing each value into 8 hours, 
the time period over which POE arrivals will occur. The resulting 
interval is [0.0015, 0.0028]. 

E. EXCEPTIONS AND WAREHOUSE REFUSALS 

Numerous unprogrammed interruptions to the demand processing 
procedure may occur. Demand exceptions and warehouse refusals 
are two such delays that, when they occur, inhibit further 
processing until manual corrective action has been taken. In 
the NSC San Diego model, the necessary corrective action will 
be taken by the exception processing unit within the Customer 
Service Division. 

A demand exception occurs when a requisition fails one of 
the many validity checks made by the demand processing program. 

If the requisition is entered from a remote terminal, the excep- 
tion, if encountered, will kick out at the remote terminal and 
be processed immediately. Using terminology that defines the 
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modeling approach, an exception resulting from a remote trans- 
action input will go to the head of the exception processing 
unit queue. Exception output from the batch processing runs 
will be routed to the exception queue and processed in IPG 
sequence. QUICK PIC exceptions will be processed together 
at the beginning of each work day. The only data available 
for computing an exception rate was the reference (e) count 
of exceptions received during the five month data base. There 
were 49,655 exceptions lodged against the 644,013 requisitions 
processed over the same period. 

Warehouse refusals occur when insufficient assets exist 
in the warehouse to issue the quantity specified on the issue 
document. This situation represents a mismatch in the recorded 
and actual on-hand quantity and indicates a reconciliation is 
required. In actual operations a warehouse refusal and partial 
issue will often occur together; i.e., some assets were on-hand 
and used to partially satisfy the customer request but the 
remainder represents a warehouse refusal because the MSIR (Master 
Stock Item Record) indicated the entire quantity was available. 
However, the model will not recognize partial issues. The occur- 
rence of a warehouse refusal will indicate that the entire quan- 
tity was NIS (Not- In-Stock) . Therefore, transactions exiting 
the processing stream as warehouse refusals will be routed 
to the exception desk/queue, processed, and removed from the 
system. Actual subsequent processing would normally lead to 
a referral based on nonavailability of assets. A 1% warehouse 
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refusal rate based on a recent NSC San Diego Quality Control 
study will be used. 

It is assumed that the exception total of 49,655 given above 
includes warehouse refusals that must be subtracted before a 
demand exception rate can be estimated. Since warehouse refusal 
rates refer to a percentage of issues rather than requisitions, 
the 1% rate will have to be applied to the number of issues 
projected from a 644,013 transaction input. Assuming a gross 
availability rate of 65%, the number of warehouse refusals over 
the five month data base is estimated to be 4,186 (0.01 x0.65 
x 644,013). The exception total must be further reduced by an 
estimated 250 per week input of nonstandard material exceptions 
that will not apply in this model. Therefore, an additional 
5,500 (250 x 22) exceptions will be excluded from the exception 
total and it will be assumed that the demand exception total 
over the five month period was 39,969 (49,655 - (4,186 + 5,500)). 
The resulting estimated demand exception rate of 6.2% (39,969 
7 " 644,013) will be used in the model. 

SERVMART replenishment requisitions are generated locally 
using the automated EPOS system. Therefore, under the assumption 
that demand exceptions seldom occur when using this automated 
procedure, SERVMART demands will not be tested for demand excep- 
tions. Similarly, provisions requests are arbitrarily excluded 
from exception testing in recognition of the limited number of 
fields that must be entered on the prepunched requisitions by 
the customer and keypunched in DPD . 
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An appropriate analysis of the demand exception rate would 
require, at the very least, exhaustive research of the UADPS- 
SP Program Processing statistics exception data and represents 
an effort that is beyond the scope of this project. Therefore, 
the relatively simple computation presented will have to suffice 
until a more accurate assessment can be made. Although a more 
recent gross availability rate of 68% is used later in the 
model, it was not considered necessary to change the demand 
exception computation, which was based on the lower (65%) availa- 
bility value. Regardless of the value used, 65% or 68%, an 
exception rate of approximately 6% is intuitively too high 
but, if nevertheless accurate, certainly worthy of management 
attention. 

F. MODELING CONSIDERATIONS 

Prior to beginning the actual modeling of the requisition 
processing components, a brief discussion of the modeling 
approach is advisable. The three principle factors influencing 
the modeling approach are the desire to gradually and system- 
atically incorporate complexity, the difficulties associated 
with modeling the timing of requisition processing, and the 
existence of a maximum node constraint of 100. 

Despite possessing many features that simplify the modeling 
process, Q-GERT appears to lack a programmed approach for accu- 
mulating then releasing all transactions after a specified time 
period. Modeling activities like messenger services, the 
accumulation of requisitions prior to a scheduled batch run. 
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and the filling of accumulator lines before releasing material 
to packing all depend on this principle and are necessary to 
approximate reality in the model. Therefore, the modeling of 
such events will have to be accomplished with FORTRAN program 
inserts. The expanded modeling capability that can be realized 
through the use of these inserts is one of the most impressive 
features of Q-GERT. Existing Q-GERT subprograms can be accessed 
by the user defined FORTRAN segment. Chapter 7 of reference 
(a) describes the use of program inserts and illustrates the 
great degree of flexibility afforded the modeler by this feature. 
However, since a stated objective of this project is to intro- 
duce and/or use the maximum number of pre-defined Q-GERT concepts, 
the use of program inserts will be limited to situations that 
can not be modeled otherwise. 

The timing of the model refers not only to the scheduling 
of messengers and batch processing runs, but also the switching 
of shifts, days, and weeks. Since the demand pattern changes 
from day to day, the arrival rate will differ each day. There- 
fore, a switching network will be developed to periodically 
replace the transaction source network. However, the IPG I 
through III percentages for autodin and POE will not be changed 
on a daily basis. Six simple weekly averages taken from Appendix 
B will be used to define the IPG percentages. This step will 
minimize the number of network modifications that must be made 
when the day of the week changes without appreciably degrading 
the model validity. Due to the complexity of timing the model. 
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a chapter will be devoted to the subject and presented after 
the model has been completed in a "free-flow" form. 

The 100 node limitation and existing time constraints pre- 
sent insurmountable obstacles to both model validation and the 
generation of representative simulation output. Validation on 
a piecewise basis could conceivably be accomplished but, as 
emphasized in the Introduction, there is a time constraint 
associated with the completion of this segment of an unavoidable 
two-phased study. Given this time limitation, the validation 
of the model, whether conducted in a piecewise fashion or through 
the analysis of initial full model runs, will have to be under- 
taken during the second phase. Network segments requiring exten- 
sive analysis during the validation process are emphasized 
throughout the remaining chapters and reiterated in the Chapter 
11 summary. Since the Q-GERT cards corresponding to the model 
developed in Chapters 6 through 10 were created, an attempt was 
made to identify a convenient network segment containing less 
than 100 nodes that could be run independently. Due to the com- 
plex relationship between the Chapter 11 disjoint timing network 
and the remaining operationally dependent segments, a represen- 
tative independent model could not be readily identified. 
Nevertheless, numerous examples of the standard Q-GERT output 
that would be generated by simulations on a model segment are 
illustrated in conjunction with the sample problems presented 
in reference (a) . 
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VI . MODELING THE ARRIVAL AND CATEGORIZATION OF REQUISITIONS 



A. ATTRIBUTE ASSIGNMENT 

Requisitions arrive at the Supply Center as a readily recog- 
nizable member of one of the categories discussed in Chapter 5. 
Therefore, the arrival process in the model will include not 
only the generation of demands, but also the designation of a 
transaction to a category through the attribute assignment 
feature of Q-GERT. Figure 6-1 shows the symbology necessary 
to indicate the assignment of a single attribute at a node. 



Attribute number 

Parameter set or constant 

Node number 




Same as 
previously 
discussed 



Distribution or 
function type 



Figure 6-1. Statistics Node Used for Attribute Assignment 

Attribute assignment information is always placed in the three 
partitions directly to the left of the node number. The attri- 
bute number affected is at the far left and the method of assign- 
ing a value to the indicated attribute is displayed in the re- 
maining two partitions. Figure 6-1 illustrates the case where 
a value from a normal distribution described by parameter set 
1 is being assigned to attribute 1 of each transaction passing 
through the node. Although a statistics node is used in the 
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example, attribute (s) may be assigned at any node type that 
has been presented. However, at each node where an attribute 
assignment occurs, a VAS (Value Assignment) card must be pre- 
pared in accordance with reference (a) instructions. Any of 
the distribution types listed in Appendix A except AT may be 
used to define an attribute assignment. 

Figure 6-2 is provided to illustrate the procedure to 
multiple attribute assignment and introduce an additional 
attribute assignment technique not given in Appendix A. 



Figure 6-2. Multiple Attribute Assignment at a Q-Node 

Attribute 1 is assigned a constant value of 1. Attribute 2 
is first being assigned a value from a normal distribution des- 
cribed in parameter set 1 and is then being changed through the 
addition of a value taken from the uniform distribution described 
in parameter set 2. Since the time to perform activity 7 is 
defined as the value of attribute 2, the service time associated 
with transactions taken from Q-node 6 is the sum of samples 
from a uniform and normal distribution. If the initial attri- 
bute 2 value assignment had occurred earlier in the network, 
only the 2+ row would have been required to change the value. 
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The bottom value assignment to attribute 3 is the incremental 
function. It indicates that attribute 3 of the transactions 
leaving the Q-node should be sequentially numbered with the 
first transaction being numbered 1. It is not necessary to 
start with 1. Any negative or positive number is an acceptable 
starting point; each successive transaction will be assigned 
an attribute 3 value that is one unit more positive than the 
value assigned to the previous transaction. 

The model will primarily use attribute assignments of the 
CO variety. Attributes 1-3 will be assigned constant values 
to represent the following requisition characteristics: 

Attribute 1 is the IPG indicator with possible values 
of 1, 2, and 3 representing IPG I, II, and III, respectively. 

. Attribute 2 is the keypunch service time taken from 
Appendix C. It will be assigned one of the following values: 

. . 0 mechanized input 

.. 0.0032 for provisions transactions 
.. 0.0067 for Special Programs requisitions 
.. 0.0071 for all other nonmechanized transactions 
Although constant keypunch service times are used in the model. 
Appendix C provides sufficient provisions and DD 1348 data to 
compute a relatively good estimate of keypunch variability. 

Attribute 3 will be used to establish ranking and pro- 
cessing priorities in the model and may be assigned any of 
the following values: 

. . 0 - Warehouse Refusal 
. . 1 - Bearer Requisition 
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. . 2 - IPG I (autodin or POE) 

. . 3 - QUICK PIC 

. . 4 - IPG II (autodin or Table 5-1 Other Category) 

• • 5 - IPG III (autodin or Table 5-1 Other Category) 

. . 6 - Not used (originally reserved for Special Pro- 

gram requisitions, but not needed) 

. . 7 - Provisions 

. . 8 - SERVMART replenishments 

B. CONDITIONAL BRANCHING 

The only branching techniques discussed thus far have been 
deterministic and probabilistic. In order to describe the 
routing of transactions based on attribute value, two additional 
forms of branching designated conditional-take-all and condi- 
tional-take-first must be introduced. Figure 6-3A illustrates 
the former type and 6-3B the latter. 




Figure 6-3A. Conditional-Take- Figure 6-3B. Conditional-rTake- 

All Branching First-Branching 

Each transaction routed through node 5 above will be forwarded 
along every exiting branch for which the specified condition is 
met. For example, using the model attribute assignments previously 
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presented , a Bearer mechanized requisition arriving at node 5 
would lead to a duplicate of that transaction being routed 
along all three branches. On the other hand, the arrival of a 
POE IPG III nonmechanized transaction would lead to an error 
message since none of the conditions would be met; each incoming 
transaction must satisfy at least one of the specified condi- 
tions for both forms of conditional branching illustrated above. 
The conditional-take-all method will not be used often in the 
model. However, it is presented to illustrate its potential 
value to the modeler. 

The conditional-take-first branching shown in Figure 6-3B 
will play a major role in the requisition processing model. 

In this form of branching, the order in which the conditions 
are to be evaluated will be specified and the transaction will 
be routed along the first branch for which the condition is 
satisfied; no further conditions will be evaluated. Recall 
that attribute 2 was the keypunch service time and was set to 
either 0 (mechanized) or the appropriate service time. After 
ensuring that attribute 2 is set for every transaction arriving 
at node 6 above, the simple branching illustrated can be used 
to route transactions to either keypunch (A2 ^ 0) or DPD if 
already keypunched (A2 = 0) . 

Conditional branching can be used at all nodes discussed 
except Q- nodes where only probabilistic or deterministic branch- 
ing is permissable. Finally, branching based on specific 
attribute values is only one of many conditions that can be used 
for the routing decision. Branching can be based on numerous 
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other factors such as current simulation time, the relationship 
of one attribute value to another, and the status (released or 
not) of a specified node. These conditions are listed on page 
146 of reference (a) . 

f 

C. THE AUTODIN ARRIVAL AND CATEGORIZATION PROCESS 

It was noted in Chapter 5 that the autodin arrival process 
was significantly different from, its POE counterpart with regard 
to both the time over which arrivals occur and the IPG categori- 
zation percentages. Therefore, it was concluded that separate 
arrivals must be modeled for autodin and POE with both display- 
ing a uniform time between arrivals due to large variations in 
the demand data. Figure 6-4 is the Q-GERT representation of 
the autodin arrival and requisition categorization process for 
one day 1 s demand at NSC San Diego. Note that node 1 is not a 
source node although it is being used to generate and mark 
transactions in a manner similar to the Figure 2-4 source node. 
When preparing a Q-GERT input card, node 1 would be designated 
a regular node with a mark time being assigned. The absence of 
the — W* indicator on the input side and the requirement for 
1 transaction to provide the initial release indicate the 
source node preceeds node 1 in the network. In fact, the source 
node will be part of the timing network referenced in the rec- 
tangle preceding node 1. This network, which will not only 
time the daily input but will also shift the day of the week, 
will be covered in a later chapter. Prior to introduction of 
the timing network, the transaction flow in the model is con- 
strained only by the delays indicated on the branches and time 
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spent at Q-nodes awaiting either service or a timing pulse. If 
no delay is indicated on a branch, the default value of (CO,0) 
applies. Note that the transaction from the timing network 
to node 1 is assigned a delay from the same interarrival dis- 
tribution as activity [T] ; this timing pulse, which activates 
node 1 for the specified 24 hour period, also represents the 
first requisition arrival of the day since it is routed along 
both branches (deterministic branching) leaving node 1. 




Figure 6-4. Autodin Arrival and Categorization Process 

Figure 6-4 illustrates the simplicity of the autodin arrival 
and categorization process. Since the requisitions are all 
mechanized, an attribute 2 keypunch service time of zero is 
immediately assigned to each demand generated. The attribute 
4=0 assignment will be discussed later. Node 2 provides 
probabilisitc branching proportional to the simple weekly 
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average IPG percentages. At nodes 3, 4, and 5 each transac- 
tion is assigned an attribute 1 value equal to its IPG. In 
addition, attribute 3 values of 2, 4, and 5 are assigned to 
IPGs I, II, and III, respectively, to establish future pro- 
cessing priorities. Modeling nodes 3, 4, and 5 as regular 
nodes is only appropriate for describing the immediate release 
of incoming transactions to DPD or Customer Services. In 
actuality, arriving transactions must await the appearance of 
a scheduled messenger. Therefore, Figure 6-5 represents a 
more realistic model of autodin processing procedures and also 
permits the introduction of two additional Q-GERT concepts, 
the match node and user functions. The Figure 6-4 value assign- 
ment of attribute 4 = 0 at node 1 was made to facilitate the 
matching process. 

Chapter 5 mentioned the absence of a well defined Q-GERT 
concept to model a scheduled messenger service. The match 
nodes used in Figure 6-5, nodes 7 and 10, and the network 
associated with them illustrate one possible messenger modeling 
scheme . 

The match node functions to delay the removal of a transac- 
tion from a Q-node until a transaction with a matching selected 
attribute value arrives at another Q-node. Q-node 5, which 
was shown as a regular node on Figure 6-4, contains IPG I auto- 
din requisitions with an attribute 4=0 assignment from node 1. 
These transactions are to be forwarded to Customer services for 
processing. However, match node 7 functions to delay the rout- 
ing until a transaction with attribute 4=0 arrives at Q-node 8. 
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Figure 6-5. Revised Autodin Arrival and Categorization Process 



When a match does occur, one transaction will depart each Q- 
node and be forwarded to nodes specified on the Q-GERT card 
describing the match node. The nodes on the output side of 
the match node may be any type previously discussed. Only 
Q-nodes, as many as five, may comprise the input side of a 
match node. The dashed lines on both sides of the node indicate 
that they are not activities and no ACT cards are required; 

Q-node cards will reference the match nodes and the match node 
card specifies the Q-node/node routing that will occur upon 
matching . 

It would be permissible to release transactions from Q-node 
5 one at a time based upon triggers sent to match node 7 from 
a Q-node in the timing network. Of course, the arriving matching 
transaction must have an attribute 4=0 and be routed to node 
9 by the match node. In that case, the timing pulses would 
simply depart the network at node 9 with no further routing 
and one requisition in Q-node 5 would be routed each time. 
However, the situation that must be modeled is a messenger 
service with a scheduled departure of all transactions in Q- 
node 5. Therefore, upon receiving a transaction having attri- 
bute 4=0 from the timing network, the nodes 83, 8, 7, 9, and 
85 logic will effect the desired instantaneous transfer of 
all requisitions in Q-node 5. 

The messenger modeled by the match node 7 network is assigned 
to Customer Services. His route includes numerous stops that 
will not be considered in the model. His arrival at DPD in 
Figure 6-5, the Broadway warehouse, and two Customer Services 
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queues will be simulated. Four complete rounds will be made 
during an eight hour working day beginning at 0700. The 
modeled route is not identical to the sequence of stops actually 
made. However, the requisition flow and subsequent delays 
that are initiated upon his arrival are realistic. Each com- 
plete round will be initiated by a timing network pulse arriv- 
ing at node 83 on Figure 6-5. The completion of one round could 
be used to initiate the beginning of thenext by using a timed 
modification of mode 83 to inhibit messenger activity after 
the working day is over. However, the required nodal modifica- 
tion, a concept that will be introduced in Chapter 7, would 
represent an unacceptable, and avoidable, level of complexity 
at this stage of model development. 

The transaction arriving at node 83 to initiate a messenger 
run is immediately assigned the indicated attribute 3 and 4 
values. Attribute 4 is assigned a constant zero value to 
force a match at node 7 if_ Q-node 5 has autodin IPG I requisi- 
tions for the messenger to take to Customer Services. The 
attribute 3 value assignment made by UF (User Function) 5, a 
FORTRAN program insert shown in Appendix D, will be the nega- 
tive of the number of requisitions in Q-node 5. If Q-node 5 
is empty, attribute 3 (AT 3) will be equal to zero, the upper 
conditional-take-first branch will be taken, and the transaction 
representing the messenger will bypass the matching process 
and be routed directly to node 85. The delay shown on the branch 
leaving node 85 represents messenger travel time to Customer 
Services where node 86 is located. Therefore, no attempt will 
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be made to route autodin IPG I requisitions from Q-node 5 to 
regular node 84 (via match node 7) when there are no transac- 
tions to process. 

If Q-node 5 does contain requisitions, attribute 3 of the 
transaction leaving node 83 will be a negative number with an 
absolute value equal to the number of autodin IPG Is waiting 
to be routed. The "messenger" will then be sent to Q-node 8 
where his attribute 4 value will be compared to the attribute 
4 value of the first requisition in Q-node 5. Since they are 
both zero, a match will occur and a transaction will depart 
each Q-node. The requisition leaving Q-node 5 will be routed 
to node 84 and then delayed 0.5 hours before reaching the edit 
queue (Q-node 33) in Customer Services. Upon leaving Q-node 
8 the messenger transaction will have its attribute 3 value 
increased by a constant 1 and routed to node 9 via the match 
node. It is important to note that the match occurred before 
the value assignment that changed attribute 3 was made; attri- 
bute assignments occur after a node is released, but before 
conditional branching criteria are evaluated. Therefore, the 
messenger could not have been assigned an attribute 4 value 
of zero at Q-node £ and ensure an attribute 4 match with Q-node 
5; the attribute 4 value assignment of zero needed for the 
match could not be made until Q-node 8 was released and, para- 
doxically, a release of node 8 could not occur until the match 
on attribute 4 was made. Therefore, the match was ensured at 
node 83 prior to the transaction's arrival at Q-node 8. 
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When the conditional branching at node 9 is encountered 
for the first time, the absolute value of the messenger attri- 
bute 3 assignment is one less than the original number of 
transactions in Q-node 5. However, since one requisition de- 
parted Q-node 5 at the initial match, the attribute 3 value 
of the messenger represents the number of requisitions remain- 
ing in Q-node 5 at the time of the branching from node 9 . 
Therefore, when Q-node 5 is empty, the messenger attribute 3 
value will be zero at node 9 and the branch to node 85 will be 
taken. If additional autodin IPG Is remain in Q-node 5, the 
messenger attribute 3 value will represent that quantity and 
the lower node 9 branch will be taken. The routing back to 
Q-node 8 has no delay associated with it and the arriving trans- 
action has AT 4 = 0 . Therefore, another match occurs, one more 
autodin IPG I departs Q-node 5, and the messenger transaction’s 
AT 3 value is decremented (in absolute value) by one unit 
before the node 9 branching conditions are evaluated. The 
lower branch from node 9 will be taken until Q-node 5 is empty. 
No simulation time is consumed by the repeated branchings back 
to Q-node 8 and, in effect, the autodin IPG Is are all removed 
(forwarded to Customer Services via node 84) at the same time. 

The messenger process was presented in detail to minimize 
the explanation needed for similar transfer networks appearing 
throughout the model. The Figure 6-5 network consisting of 
nodes 81, 82, 6, 10, 11, and 12 is logically equivalent and 
functions to route all autodin and POE transactions in Q-node 
6 to a scheduled DPD batch processing run initiated by the 
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arrival of a transaction at node 81. The batch processing 
procedure is addressed in Chapter 8. Note that the transaction 
leaving node 82 is lost to the system vice routed in a manner 
similar to the messenger leaving node 85. This approach is 
permissable and node 82 must be included to permit the branch- 
ing evaluation at nodes 81 and 12 prior to destroying the 
transaction; i.e., the upper branches of nodes 81 and 12 could 
not have been used to destroy the transaction through omitting 
a node to receive the transaction. The branch description 
provided in the ACT (activity) input card specifies the branch- 
ing condition to be evaluated and an ACT card must contain a 
start and end node. On the other hand, the transaction leaving 
node 85 is routed to node 86 instead of being lost to the sys- 
tem. Consequently, node 85 is not actually needed. The upper 
branches from nodes 83 and 9 could have been assigned identical 
messenger delays and routed directly to node 86 . 

Three additional points must be made regarding Figure 6-5. 
First, Q-node 6 was added to the Figure 6-4 network to queue 
IPG II and III autodin and POE demands for batch processing. 
This was done not only to comply with the requirement that only 
Q-nodes may serve as match node input, but also to model trans- 
action waiting times; regular nodes such as nodes 3 and 4 can 
not lead to a delay unless transactions are being accumulated 
as described in Chapter 4. Secondly, although a match node 
may have multiple Q-nodes on its input side, one match node 
could not be used to empty Q-nodes 5 and 6; the circuitry 
associated with each Q-node represents a different ’’messenger 
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system" with a different schedule and, more importantly, the 
required matching transaction from every input Q-node would 
cease to exist when the Q-node having the least initial number 
of requisitions was empty. Finally, all the Q- nodes on Figure 
6-5 rank transactions on a FIFO basis. Q-node 6 indicates this 
fact. The other Q- nodes are assigned no ranking designator 
to indicate that the default procedure, which is also FIFO, is 
being used. 

It should be apparent that match nodes can be best used to 
model situations like programmed delays prior to routing of 
individual transactions and awaiting the arrival of several 
(up to five) dissimilar components before commencing an assembly 
operation. The Figure 6-5 messenger application is cumbersome 
at best. It represents a considerable investment in nodes to 
provide the additional network logic to effect the transfer 
and model messenger travel time. Since the dashed lines to 
and from a match node do not represent activities, they can not 
be modeled as a delay. However, the only available alternaitve 
is a variable resource allocation technique that does not repre- 
sent a significant savings in the number of nodes consumed. 
Resources will be introduced in Chapter 7 and the use of a 
variable resource scheme to model a timed release of numerous 
transactions will be introduced in Chapter 8. 

Finally, note that there are no post-arrival delays assigned 
to the requisitions during the categorization process leading 
to arrival in Q- nodes 5 and 6. Demand categories are recogniza- 
ble upon arrival and therefore require no categorization time. 
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In addition, the sequential activity numbers assigned to each 
branch on Figure 6-4 are omitted on 6-5. Branches that do 
not contain activities of interest such as interarrival dis- 
tributions and service functions referenced on output will 
not be assigned a specific number and descriptive label. 
Therefore, only the interarrival branch on node 1 is numbered. 
The remaining branches will be automatically numbered by the 
Q-GERT .Analysis Program. 

Figure 6-5 represents events occurring in DPD . Autodin 
tape input is actually received in the communications center 
and routed to DPD by messenger for segregation of IPG Is and 
batch processing of IPG II and III demands. It was not con- 
sidered essential to model the communications center activity. 
The batch autodin processing is contingent upon the arrival 
of input that may have been waiting in the communication center; 
on Figure 6-5, a proportional delay will be encountered in 
Q-nodes 5 and 6 . 

The input to Q-node 6 shown arriving from Figure 7-7 nodes 
100, 105, and 111 consists of mechanized POE input including 
SERVMART , keypunched IPH III DD 1348s, and Special Program 
requisitions. The processing of these categories is discussed 
in Chapter 7. Their inclusion in Q-node 6 models the concurrent 
processing of autodin and available POE input. 

D. THE POE ARRIVAL AND CATEGORIZATION PROCESS 

Figure 6-6 depicts the POE arrival and categorization pro- 
cess. Although the analogous autodin process was modeled solely 
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on IPG considerations, the POE model must account for many 
additional subcategories. Aside from the addition of cate- 
gories, the model does not represent a significant increase 
in complexity. 

The POE interarrival process was presented in Chapter 5 
and need not be discussed further. Demands arriving at node 
14 are probabilistically routed in relation to the specified 
category's percentage of Thursday demand. SERVMART replenish- 
ment requisitions, averaging 255 per day, represent 6.3% of 
total daily demand of 4,053 (2551 Hot Line, 550 Provisions, 

107 Special Programs IPH II, 590 Special Programs IPH III, 
and 255 SERVMART). Provisions represent 13.6% and Special Pro- 
gram IPG II and III demands account for 2.6% and 14.5%, respec- 
tively. That consumes 37% of the daily average and leaves 63% 
to be distributed among the Hot Line POE IPGs . The Hot Line 
weekly average percentages by IPG are 5.64% (I), 57.14% (II), 
and 37.22% (III) . These values are indicated on the applicable 
branches leaving node 22. As mentioned, this apportionment 
applies to the 63% of the input leaving node 14. The mechani- 
zation split of 70% nonmechanized and 30% mechanized and the 
assignment of keypunch service times occurs at nodes 15, 20, 
and 21 before the Hot Line IPG branching at node 22. This 
sequencing models the assumption that the mechanization percen- 
tage is constant across all IPGs . 

All categories except Hot Line simply have the appropriate 
attribute values assigned at regular nodes 16 through 19 and 
are forwarded to Q-node 25 to await the messenger modeled by 
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Figure 6-6. POE Arrival and Categorization Process 




the nodes 28, 29, 30, 86, and 87 logic. Special Program de- 
mands, being identifiable by their keypunch value assignment 
of 0.0067, were not assigned distinct attribute 3 values at 
nodes 18 and 19; the values assigned correspond to the autodin 
IPG II and III attribute 3 designators shown on Figure 6-5. 

All Hot Line IPG Ills and mechanized IPG IIs are also shown 
going directly to Q-node 25. This branching deviates from 
reality in the sense that all POE Hot Line input is counted 
and edited in Customer Services. However, mechanized IPG IIs 
and all IPG Ills usually arrive in batches and are necessarily 
afforded an extremely cursory edit of a duration that is 
insignificant with respect to time awaiting the messenger. 
Therefore, these requisition categories will bypass the routing 
through Customer Services editing before arriving at Q-node 25 . 
To compensate for the reduced edit queue input; the number 
of servers performing the edit function, which was specified 
as 2 in the reference (b) study, will be limited to 1. 

Hot Line IPG IIs are proportioned into the QUICK PIC (9%) 
and Table 5-1 Other (91%) categories at node 23. The QUICK 
PIC percentage was computed using an average daily input of 
162 and dividing this value by the average Hot Line IPG II 
input over the entire week; therefore, this percentage will 
not change as the day of the week changes in the completed 
model. The remaining 91% of the Hot Line IPG II input is con- 
ditionally routed at node 31 based on the keypunch service time 
attribute. Those that do not require keypunch are forwarded 
to Q-node 25 and will be batch processed in DPD . The remaining 
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IPG II requisitions leaving node 31 are routed to Customer 
Services to be edited, keypunched, and put in-process. All 
QUICK PICs, mechanized or not, are sent to Customer Services. 

IPG I demands are divided into Bearers and Others at node 24 , 

f 

assigned a processing priority designator (attribute 3) at 
nodes 26 and 27, and forwarded to Customer Services. The 
Bearer percentage was developed from Table 5-2. 

Figure 6-6 indicates that SERVMART Replenishment requisi- 
tions and QUICK PIC arrive uniformly over the day. In actuality, 
the SERVMART operation at NSC San Diego is a mechanized system 
called EPOS (Electronic Point of Sale) which generates a daily 
replenishment tape that is forwarded to DPD for overnight/ 
weekend processing. Therefore, the mark time for the SERVMART 
replenishments will be premature. However, it will be on the 
correct day and be more indicative of the actual delay between 
real time reorder recognition and the subsequent replenishment 
issue. QUICK PIC, as described in Chapter 5, is a system 
featuring the submission of requisitions at designated area 
locations. They are picked up and delivered to Customer Ser- 
vices during the day shift, but are usually not processed until 
the second shift. Therefore, the model assumption of uniform 
arrival rate over the day shift followed by processing on the 
second shift does not introduce a significant distortion of 
reality. 

It was stated that the percentages indicated on the branches 
leaving node 14 represented daily averages as a percentage of 
total Thursday demand. Consequently, as the model is stepped 
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through the week, these percentages should change. However, 
in actual model operation these values will remain constant 
and only node 13 and the interarrival logic associated with 
it will be revised/ replaced . This procedure will theoretically 
result in the volume of special category (Provisions, Special 
Programs, and S ERVMART ) demands varying proportionally with 
the daily level of demand as defined by the interarrival dis- 
tribution. This appears sufficient in view of the Chapter 5 
discussion of the nature of the special category statistics. 

The messenger logic associated with Q-node 25 represents 
the continuation of the routing that was initiated at node 
83 on Figure 6-5. The logic is identical to the autodin IPG 
I transfer network. The contents of Q-25 are forwarded from 
node 99 to DPD keypunch node 100 after encountering the indi- 
cated delay. When Q-node 25 is empty, AT 3 = 0 , the messenger 
departs from node 87 and proceeds to node 70 on Figure 7-6 to 
pick-up IPH I issue documents destined for the Broadway ware- 
house complex. 
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VII. CUSTOMER SERVICES AND DPD KEYPUNCH 



A. Q-GERT RESOURCES 

Prior to discussing the Customer Services model segment, 
the concept of Q-GERT resources must be introduced. Figure 
7-1 portrays a keypunch queue and service activity containing 
two identical servers. 



Figure 7-1. Simple Queue and Service Activity 

As servers become idle, transactions are removed from Q-node 
1 and placed in service for a period equal to the transaction's 
attribute 2 value. Transactions are ranked in the Q-node based 
on their attribute 3 value with the smallest value first. This 
simple network will perform the keypunch function and automat- 
ically be included in the Q-GERT Program statistical output. 
Average transaction waiting time in Q-node 1 and the percentage 
of time each server is busy are among the statistics generated. 
This approach would be both efficient and sufficient for des- 
cribing a single or double shift operation as long as the number 
of servers remained constant. However, the second shift at 
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NSC San Diego has fewer personnel at all work stations that 
remain active. Therefore, a procedure to model a change in 
the number of servers at a given point in time is needed. Q- 
GERT concepts previously introduced do not provide this capa- 
bility although it may be possible, with a great degree of 
difficulty, to devise a user function that will do it. Thus, 
the concept of replacing the server (s) in a network segment 
with a variable resource allocation scheme is illustrated in 
Figure 7-2. 
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Figure 7-2. Allocate and Free Nodes 

Subject to initializing conditions that will be presented 
later, the Figure 7-2 network performs the same function as 
the Figure 7-1 symbology. The resource type specified on the 
left side of allocate node 2 implies that resources must be 
categorized and numbered in accordance with the function they 
perform. If Q-node 1 contains documents to be keypunched, then 
resource type 1 must have a keypunch capability. This same 
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resource could, however, be used elsewhere in the network 
for dissimilar tasks if appropriate. A RES (Resource) card 
is used to define each type of resource, provide the initial 
system capacity, and list the allocate nodes associated with 
the resource type. The following format could be used to 
describe the Figure 7-2 network: 



This resource designation could apply if it was determined 
that keypunch personnel in Customer Services and DPD were 
undistinguishable . There may be 15 day shift keypunchers, 2 
in Customer Services and 13 in DPD, processing transactions 
from the Q-nodes preceeding Customer Services allocate node 2 
and DPD allocate nodes 7 and 8. If the type 1 resource were 
limited to Customer Services keypunchers working only on trans- 
actions in Q-node 1, the 15 would be changed to 2 and the 
allocate nodes limited to node 2 only. 

Returning to Figure 7-2, the allocation of a resource, when 
available, to a transaction in Q-node 1 effectively "captures" 
that resource and routes it with the transaction until a free 
node is encountered. Therefore, a resource would flow with a 
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requisition through node 3, encounter a delay equal to the 
transaction attribute 2 value, and then be released and re- 
turned to allocate node 2 by free node 4 . The resource re- 
mained captured, and thus unavailable, for the same period of 
time a Figure 7-1 server would be busy. 

Consider the situation described on the illustrated RES 
card example. DPD and Customer Services keypunchers were 
assumed interchangeable. Free node 4 might then have been 
displayed in one of the following ways with the indicated 
allocation scheme: 




( LJ >8 I 18,2 71 



ED 



Free Node Allocation Examples 

The multiple allocation designations under the three leftmost 
free nodes are provided to illustrate that each vertical group- 
ing describes an identical reallocation scheme. The | 2 , 7 , 8 [ 
allocation on the leftmost node is identical to the RES card 
order and specifies that allocate nodes 2, 7, and 8 should be 
reviewed in that order for the possible allocation of freed 
resources. However, the three allocation schemes directly 
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below the [2,7,8] indicator provide the same allocation order 
because all RES card allocate nodes not shown under the free 
node will also be screened in the RES card order. Therefore, 
the blank entry indicates the RES card order should be followed. 
The fT] and f 2 , 7 1 schemes achieve the same effect because the 
remaining allocate nodes using Type 1 (keypunch) resources 
would be reviewed in the order specified on the RES card. 

The second and third free nodes illustrated provide examples 
that again screen all three allocate nodes using resource type 
1 but specify a different allocation order than the RES card. 

The effect under each free node is the same due to the automatic 
inclusion of the remaining RES card nodes. The right-most free 
node, however, will reallocate only to allocate node 2. The 
specification of the negative value eliminates the RES card 
review and limits reallocation attempts to the ordered sequence 
of allocate nodes preceding the negative value at the free node. 
Therefore, the designation 8 , 2 ,-l1 results in an attempt to 
apply freed resources at allocate node 8. Any remaining re- 
sources would then be applied to allocate node 2 if they were 
needed there. If freed resources remained after sequential 
allocations at nodes 8 and 2, they would become inactive rather 
than applied to node 7. 

Any transaction can be used to initiate the freeing of re- 
sources up to the RES card capacity at a free node. In particu- 
lar, the arriving transaction need not have resources allocated 
to it. If the number of resources to be freed is greater than 
the number idle, the quantity of busy resources necessary to 
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equal the freed quantity will immediately be idled. Therefore, 
if these busy resources are functioning in a server capacity, 
they will immediately "leave their transaction" and prohibit 
the modeler from interpreting resource utilization output as 
identical to server statistics. 

Figure 7-3 illustrates a modeling scheme that would be 
particularly relevant to stock point operations. 
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Figure 7-3. Issue and Receipt Processing 

As defined on the RES cards, personnel processing issues are 
categorized as a different type of resource than receipt pro- 
cessors. The RES card also illustrates that there are additional 
issue processing network segments using allocate nodes 21 and 
31. The blank allocation block under free node 13 indicates 
the RES card sequence will be followed when allocating freed 
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resources. The free nodes associated with allocation nodes 



21 and 31 may have allocation schemes of | 21 , 31, T] and 
31 , 2 , 2T , respectively, Using that scheme, all resources 
would "remain in place" as long as there were issues to be 
made. The receipt processing network would function in a 
similar manner although the receipt processing capacity is 
10 (from the RES card) as compared to 30 issue resources. 

Realistically, these two types of resources are inter- 
changeable and a capability to transfer reousrces between the 
receipt and issue functions exists. Figure 7-4 is a simplified 
version of the Q-GERT symbology effecting a conditional trans- 
fer of resources based upon backlog consideration. This exam- 
ple will serve to introduce the AL (Alter) node, which is used 
to change the resource capacity specified on the RES card. 

At node 30, an arriving transaction is assigned an attri- 
bute 1 value computed by UF (User Function) 7. This FORTRAN 
subprogram would examine the issue and receipt Q-nodes to 
determine whether resources should be transferred from issue 
to receipt processing (Al = 1) , receipt processing to issue 
(Al = 2) , or remain as assigned on the RES card (Al = 3) . A 
second user function, which is designated UF8, will compute 
the number of resources to be transferred and assign that value 
to attribute 2 of the transaction. The conditional-take-f irs t 
branching from node 30 is based on the attribute 1 value assigned 
and, if the user functions indicate that resources should be 
shifted from issue (Type 1) to receiving (Type 2) , the upper 
branch will be taken. Alter node 40 will reduce the Figure 7-3 
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Figure 7-4 . Alter Node Network 

RES card capacity of 30 by the value of attribute 2 of the 
arriving transaction. However, unlike the free node, the 
alter node will wait until resources are idle before seizing 
them. Alter node 41 will then increase the receiving resources 
by A2 units and allocate them as specified on the RES card and 
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described in the free node discussion. The eight hour delay 
on the deterministic branching from node 41 indicates the 
resources will remain reassigned the entire workday and then 
altered to equal the original RES card capacities at nodes 
42 and 43. The transaction leaving node 42 departs the sys- 
tem; node 43 output is assigned a 16 hour delay then routed 
back to node 30 to initiate the backlog evaluation process 
again . 

The second branch (A1 = 2) operates in a similar manner 
but transfers assets from receiving (Type 2) to issue for the 
day. If it is determined that no resource shifts are required, 
the bottom branch (A1 = 3) is taken from node 30 and a 24 hour 
delay is encountered before the next backlog evaluation. 

The applicability of resource capacity altering to the 
modeling of breaks and shift changes should be apparent. A 
resource allocation network could even be used to provide a 
messenger service; the amount of the messenger resource made 
available by an alter node could be set to a constant value 
or even equated to the number of queued transactions waiting 
to be routed. After the routing was completed, the messenger 
capacity would immediately be altered to zero to preclude the 
movement of transactions before the next scheduled messenger run. 

B. CUSTOMER SERVICES 

The Q-GERT representation of the NSC San Diego two shift 
Customer Services operation is shown on Figures 7-5 and 7-6. 
Autodin IPG I input from node 84 on Figure 6-5 and POE input 
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from nodes 26, 27, 31, and 32 on Figure 6-6 are shown enter- 
ing the edit queue, Q-node 33. Nodes 34 through 36 model the 
edit server as a resource as described earlier in this chapter. 
The time to edit, which is indicated by the delay on the branch 
between nodes 35 and 36, is a constant 0.002 hours (7.2 seconds) 
as specified in reference (b) . The RES card image shown under 
node 34 indicates there is one unit of the edit resource that, 
when freed, is to be allocated at node 53, then 34. Node 53, 
which is part of the second shift exception processing network 
in the lower left portion of Figure 7-5, is discussed below. 
During the day shift, the edit resource will be processing 
requisitions from Q-node 33 only. The free node 36 allocation 
scheme of 53,34 is identical to the RES card and therefore 
could have been omitted. 

The conditional-take-first branching from node 36 functions 
to provide special processing for QUICK-PIC transactions. They 
are modeled as being edited upon arrival and then stored in 
Q-node 37 until released by a timing network transaction arriving 
at node 39 . Once again the requisition transfer system des- 
cribed in Chapter 6 effects the instantaneous timed release of 
the QUICK PIC transactions from node 41 to either node 43 if 
keypunch is required, or to DPD if mechanized (A2.EQ.0). The 
model will provide the transfer at 1800 on each working day 
for the following two reasons: (1) QUICK PIC, with an A3 = 3 

designator, should be withheld from the keypunch S/3-ranked 
queue (Q-node 43) long enough to maximize the number of non- 
mechanized IPG II demands (A3 = 4) placed in-process before 
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Figure 7-5. Customer Services (Part 1) 



the 1800 backorder/in-process release program is run in DPD; 
and (2) once entering the keypunch queue, the relatively small 
attribute 3 value should ensure all QUICK PICs are keypunched 
prior to the end of the second shift. Theoretically, QUICK 
PIC processing will cease only upon the arrival of an autodin 
IPG I; POE input terminates at 1600 in the model. A discussion 
of the IPG II in-process and subsequent release relationship 
was presented in Chapter 5 . 

The requisitions routed from node 36 to node 43 via regu- 
lar node 42 will be Bearers, other IPG Is, and IPG IIs. Each 
category will not only be keypunched if necessary (A2.NE.0), 
but will also be entered for remote processing. Since the 
nodes 44 through 46 resource allocation network performs the 
joint keypunch and enter action based upon the transaction's 
attribute 2 value, an entry time of 0.0015 hours, or approxi- 
mately 5 seconds, is added to the keypunch time at node 42. 

The transactions are then routed to Q-node 43 where they, and 
QUICK PICs arriving at 1800, are processed by the CSKEY (Cus- 
tomer Services Keypunch) resources illustrated on the RES card 
image under allocate node 44. The indicated day shift capacity 
of two will be reduced to one at 1600 each day by an alter node 
in the timing network. Note that two Q-nodes, 43 and 61, con- 
tain transactions that use Customer Services keypunch resources. 
Demand exceptions and warehouse refusals for all requisition 
categories are processed by the Exception Unit and returned to 
Q-node 43 or 61 for exception keypunch and, except for QUICK 
PIC, immediate entry. If there are transactions in both Q-*nodes , 
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the queue selection priority scheme located in the upper left 
partition of allocate node 44 is used to determine the next 
transaction processed when resources are freed. 

Table 7-1, which was reproduced from reference (a), lists 
the queue selection rules that may be specified at either 
allocate nodes or S-nodes (Selector nodes) . The ASM (Assembly 
Mode) option listed last in the table may only be used at S- 
nodes. Allocate node 56 on Figure 7-5 was originally modeled 
as an S-node. The description of the node 56 demand exception 
processing network will include an introduction to the use of 
S-nodes . 

The POR (Preferred Order) specification at allocate node 
44 was selected as the most realistic option available in 
Table 7-1. Assume that Q-node 61 was not included and all 
processed exceptions leaving node 60 were routed to Q-node 43 
and ranked as indicated by their attribute 3 value. Since de- 
mand exceptions are encountered on all requisition categories 
except SERVMART and provisions (attribute 3 values from 1 to 
5) , the large volume of higher priority demands arriving at 
Q-node 43 could possibly delay the keypunching and reentry of 
IPG III exceptions for an inordinately long period. In reality, 
demand exceptions are not processed on a strict priority basis 
by the Exception Unit. Exceptions often arrive at keypunch 
batched by type of exception and containing both IPG II and 
III requisitions. Keypunch, in turn, will process the entire 
batch sequentially unless interrupted by the arrival of an IPG 
I. Therefore, requisitions having large attribute 3 values 
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Table 7-1. Priority rules associated with allocate 
and S-nodes for selecting from parallel queues 



Code 

POR 

CYC 

RAN 

LAV 

SAV 

LWF 

SWF 

LNQ 

SNQ 

LNB 

SNB 

LRC 

SRC 

ASM 



Definition 



Priority given in a preferred order. 

Cyclic Priority - transfer to first available 
Q-node starting from the last Q-node that was 
selected . 

Random Priority - assign an equal probability to 
each Q-node that can be selected. 

Priority given to the Q-node which has had the 
largest average number of transactions in it to 
date . 

Priority is given to the Q-node which has had the 
smallest average number of transactions in it to 
date . 

Priority is given to the Q-node for which the 
waiting time of its first transaction from its 
last marking is the longest. 

Priority is given to the Q-node for which the 
waiting time of its first transaction from its 
last marking is the shortest. 

Priority is given to the Q-node which has the 
current largest number of transactions in it. 
Priority is given to the Q-node which has the 
current smallest number of transactions in it. 
Priority is given to the Q-node which has had 
the largest number of balkers from it to date. 
Priority is given to the Q-node which has had the 
smallest number of balkers from it to date. 
Priority is given to the Q-node which has the 
largest remaining unused capacity. 

Priority is given to the Q-node which has the 
smallest remaining unused capacity. 

Assembly mode option - all incoming queues must 
contribute one transaction before a processor may 
begin service (this can be used to provide an 
"AND" logic operation); S-nodes only. 
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aren't actually waiting as long as a direct input into Q-node 
43 would theoretically cause. This observation indicated that 
the addition of a second Q-node for exception unit output was 
advisable. Consideration was given to routing all exceptions 
to Q-node 61, which would be assigned an S/3 ranking, and estab- 
lishing a POR (Preferred Order) queue selection rule at allocate 
node 44 with Q-node 43 as the preferred queue. This procedure 
would inhibit any processing of node 61 exceptions unless 
Q-node 43 was empty. The expected volume at node 43 caused 
the rejection of this approach; a large percentage of incoming 
requisitions will pass through Q-node 43 while only 6.2% of 
all demands will encounter exceptions. Similar volume considera- 
tions led to discarding an "all exceptions to node 61, LNQ 
queue selection" approach with an S/3 ranking procedure in the 
queue. Although this technique would place warehouse refusals 
and IPG Is (attribute 3 values of 0, 1, and 2) at the head of 
Q-node 61, it again appeared likely that the high volume in 
node 43 would preclude the actual expeditious processing 
afforded warehouse refusals and IPG Is. Therefore, the indi- 
cated compromise routing was established. Warehouse refusals 
and IPG Is are routed on the A3.LE.2 branch to the higher volume 
queue, node 43, where they are ranked on a "smallest value of 
attribute 3" basis. This places warehouse refusals, which 
possess a zero attribute 3 value, first in the queue and models 
NSC San Diego management policy. The IPG Is, having attribute 
3 values of 1 and 2, will therefore be processed directly after 
the warehouse refusals to reflect the special management attention 
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given this category by Customer Services. The S/3 ranking 
in exception processing Q-nodes 49 and 52 also implies a 
strict priority exception processing procedure is used. While 
this is always true for the IPG Is and the IPG I Is put in- 
process at Customer Services keypunch, recall that it is not 
completely factual for batch processed IPG II and III excep- 
tions arriving at Q-node 49. Therefore, an F (First-In-First 
Out) queue ranking rule was specified at Q-node 61 to model 
the actual occurrence of IPG III exceptions being reentered 
by Customer Services before IPG IIs originating at a later 
batch run. This modeling approach will partially offset the 
somewhat erroneous strict priority processing technique used 
in the Exception Unit. 

An LNQ (Largest Number in Queue) designation at allocate 
node 44 would have modeled a cyclic processing procedure once 
the queues contained the same number of transactions. This 
was considered too great a departure from reality. Therefore, 
the POR option with Q-node 43 preferred was selected despite 
the much higher volume arriving at Q-node 43. This technique 
will result in batch keypunch and entry of IPG II and III 
exceptions on a FIFO basis once the processing of the contents 
of Q-node 61 begins; i.e., when Q-node 43 is empty. This 
approach is more realistic than it may appear. The technique 
used should result in IPG II and III exeptions begin batch 
processed on the Customer Services evening shift, which is 
precisely what actually often occurs. The foregoing discussion 
emphasizes the complexity of the exception processing/Customer' 
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Services keypunch relationship and presents the myriad fac- 
tors that entered into the modeling decision. 

Returning to Figure 7-5 at free node 46, the keypunched 
QUICK-PIC requisitions, which were not entered by Customer 
Services, are removed and forwarded to a special DPD queue. 

The remaining transaction are assessed a variable delay prior 
to node 47 to represent remote processing time. Although 
entering a requisition frees the keypunch resource, the trans- 
action is delayed until processing is completed. Activation 
of the on-line remote demand processing program is based upon 
time-volume considerations. Requisitions entered through remote 
terminals are queued and processed at six minute intervals 
unless 30 transactions accumulate before the time expires. 
Nevertheless, delays in the receipt of a response (issue docu- 
ment, referral, or exception) that exceeded 15 minutes were 
frequently observed. Lengthy delays were probably attributa- 
ble to time awaiting the issue document punch routine, a rela- 
tively slow operation when compared to CPU processing times. 

In additiona, two minute turnaround times were noted during 
low workload periods when a six minute wait could reasonably 
be expected. Therefore, the processing time assigned at node 
42 will be taken from a normal distribution having a mean of 
eight minutes and a standard deviation of 2.5 minutes. Mini- 
mum and maximum processing times of two and 17 minuts are also 
specified. 

The branching from node 47 models the 6.2% demand exception 
rate developed in Chapter 5. During the day shift, exceptions 
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occurring from Customer Services remote entries will be 
routed through node 48 to Q-node 49 where, via allocate node 
56, three type 8 resources (servers) are available to process 
them at the reference (c) DIMES rate of 0.0271 hours (1.626 
minutes) per transaction indicated between nodes 57 and 140. 

The POR designation at allocate node 56 gives Q-node 50 pro- 
cessing priority over Q-node 49. Therefore, exception processing 
on all requisition categories in Q-node 49 - from both remote 
and batch input - is delayed until the QUICK PIC demand excep- 
tions and warehouse refusals residing in Q-node 50 have been 
completed. While this approach may appear to introduce an 
unacceptable delay on IPG I and II transactions residing in 
Q-node 49, the relatively small expected volume in the priority 
queue should eliminate any extraordinary delays. QUICK PIC 
exceptions, which can be epxected to occur at a 6.2% rate on 
less than 200 transactions per day, will all appear at the head 
of Q-node 50 at the beginning of each working day and immediately 
be processed when resources become available at 0730. Ware- 
house refusals, on the other hand, not only occur at a relatively 
low 1% (of issues) rate, but are also routed by messenger with 
nearly two hours between scheduled arrivals. Therefore, with 
three exception processing resources available, considerable 
attention will be given to Q-node 49 exceptions in the period 
between warehouse refusal arrivals. The B/3 ranking scheme 
at Q-node 50 ensures that QUICK PICs, with the bigger attribute 
3 value of 3, are processed before warehouse refusals. 
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The network segment consisting of nodes 56, 57, and 140 
was originally modeled using the S-node logic shown below. 



QUEUE 

SELECTION 




The POR designation in the queue selection partition functions 
exactly like the identical specification in an allocate node. 

Any of the queue selection rules listed in Table 7-1 can be 
used with an S-node. In addition, a server selection priority 
rule may be specified in the lower left partition if a choice 
between dissimilar servers must be made. Since the S-node above 
routes transactions to three identical demand exception servers 
at the activity designated number |3] , no server selection 

rule was required. Chapter 5 of reference (a) details numerous 
modeling enhancements that can be realized through the use of 
various permutations of the queue and server selection rules. 

The S-node approach was discarded because the servers could 
not be removed or reduced when the shift ended. Therefore, the 
processing of backlogged transaction in Q-node 49 will continue 
during the evening and midnight shifts until the queue is empty. 
This condition invalidated the S-node approach; exceptions 
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remaining in Q-node 49 at the end of the normal working day 
will not be processed until the servers become available again 
the following day. Therefore, a resource allocation approach, 
which permits the application and removal of resources from 
the timing network, was adopted to replace the S-node network. 

After an exception has been processed, it is routed to free 
node 140 where the exception processing resource is freed 
and the indicated branching occurs to preclude assigning an 
entry time to QUICK PIC transactions. The time to keypunch 
an exception is assumed to equal the standard requisition 
keypunch time of 0.0071 hours. Following the node 58 or 59 
keypunch processing time assignment, the previously mentioned 
node 60 conditional branching to the Customer Services queues 
occurs. QUICK PICs encountering exceptions are not expedited 
in an attempt to make the 1400 deadline. Upon discovering 
that his material is not available for pick-up, the customer 
has the option of coming in and obtaining the material as a 
Bearer or waiting an additional 24 hours. Actually, the QUICK 
PIC exception would be processed before queuing for the late 
evening transfer to DPD . However, sending it to Q-node 37 and 
clearing the exception after 1800 introduces no erroneous de- 
lays while eliminating the need for more complex branching. 

The foregoing discussion applied to day shift exception 
processing. If an exception occurs on a requisition entered 
by the Customer Services second shift, it will be transfered 
from node 48 to node 51 by means of a Q-GERT technique called 
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nodal modification. The symbology shown between nodes 48 and 
51 can be interpreted in the following way: 

. Upon completion of activity i, which will be an 8.5 
hour delay in the timing network to represent the day 
shift, node 51 will replace node 48. 

. Node 51 will remain in the network until activity j 
has been completed to signal the end of the second 
shift . 

While node 51 is in the network, transactions (exceptions) 
arriving at node 48 will be rerouted to node 51 and forwarded 
to Q-node 52, the second shift exception processing queue. 
Allocate node 53 indicates that resource type 1 is used to 
correct the exception. Free node 55 attempts to reallocate 
freed resources at nodes 53 and 34, which follows Q-node 33, 
the edit queue. Free node 36 of the edit resource network also 
attempts to reallocate at node 53 first. During the day shift, 
an allocation at node 53 will not be made because Q-node 52 
will be empty; i.e., no exceptions are being routed there until 
after 1600. However, during the second shift, editing of Q-node 
33 will terminate when an exception occurs because the edit 
resource, when freed at node 36, will be allocated to the excep- 
tion first. The model is realistic. Editing is interrupted 
to process exceptions occurring, in general, on autodin IPG Is 
and IPG IIs being put in-process. Of course, requisitions and 
exceptions remaining in Q-nodes 43 and 63 after the day shift 
are also being keypunched and/or entered. The routing from 
node 55 need not incorporate the QUICK PIC consideration modeled 
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by node 57; QUICK PICs are not entered from Customer Services 
by remote and all exceptions originating in the special QUICK 
PIC overnight batch run arrive at Q-node 50 each morning. 

Requisitions branching without exception from node 47 are 
first subjected to the conditional branching at node 62 where 
Warehouse refusals are removed. The existence of a warehouse 
refusal indicates that material was not available and, theoret- 
ically, the modeled referral will automatically occur. In 
practice, material sometimes does become available from a 
variety of sources. However, no attempt will be made to model 
the numerous factors that can invalidate a warehouse refusal. 

The NSC San Diego February 1980 material availability or POE 
(Point of Entry) effectiveness percentage of 68% is applied 
at node 63. Requisitions branching as not available (referrals) 
are routed to node 65 on Figure 7-6 along with the referrals 
originated by warehouse refusals. Requisitions that can be 
satisfied are routed to node 64. All IPG II and III demands 
are sent to the DPD in-process queue where they will be released 
at 1800 daily. Although no IPG Ills entered Customer Services 
at the edit queue, they do arrive as exceptions which, when 
corrected, are put in-process by keypunch resources. IPG Is 
branch from node 64 as either Bearers or Others due to the dis- 
tinct processing differences shown in Figure 7-6. 

As indicated by the branching from nodes 69 and 95 on 
Figure 7-6, it will be assumed that 15% of all demand (provi- 
sions excluded) is for material warehoused at the National City 
complex. The remaining 85% is lodged against assets at the 



94 




95 



Figure 7-6. Customer Services (Part 2) 




Broadway location with bin and bulk material contributing 65% 
and 20%, respectively. The IPG Is were subcategorized at 
node 64 (Figure 7-5) prior to the location designation to 
ensure each subcategory would be assigned a representative 
National City issue percentage. A separate messenger service 
transports non-Bearer IPG Is to National City. The network 
representing this document flow consists of nodes 70 through 
75 plust 90 on Figure 7-6. Although it is not included in 
the model, an IPG I processing idiosyncracy should be mentioned; 
all IPG I issue documents. Bearer or Other, are printed and 
output at Customer Services (Broadway) regardless of the material 
location. There is a remote terminal at National City through 
which requisition entry is initiated. However, even if an IPG 
I request for National City material were entered there, the 
issue document would have to be obtained from Broadway (Cus- 
tomer Services) and transported back to National City by the 
Bearer or messenger. Since National City entry workload is 
included in the reference (e) totals and all IPG I issue docu- 
ments originate in Customer Services, a separate National City 
entry station in the model was not considered necessary. The 
existing NSC San Diego procedure introduces IPG I processing 
delays for National City material. Bearers may encounter a 
delay equal to the time of a round trip to National City. Other 
IPG Is for National City material will normally be entered at 
Broadway and will experience a delay that depends on the timing 
of the next National City messenger run. Therefore, the only 
delay missing in the model is the Bearer travel time from 
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National City to Broadway; i.e., a Bearer entered at National 
City for National City material. This omission is not con- 
sidered crucial; travel time (30-45 minutes) is concurrent 
with the entry and document preparation time that, as dis- 
cussed above, is normally distributed with a possible maximum 
of 17 minutes. 

Following the issue category determination at nodes 65 
and 95, identical DIMES issue time standards are assigned as 
attribute 5 to Bearers at nodes 96 through 98 and to Other 
IPH Is at nodes 70, 76, and 77. The Broadway bin issue time 
of 0.068 hours is a hot line issue time in contrast to the 
lower AMHS (Automated Material Handling System) bin issue time 
of 0.45 hours for requisitions lotted in DPD . An IPG I bin 
issue functions as an interrupt to AMHS lotted, location se- 
quenced bin issues. This random deviation from the lotted 
location pattern will normally increase the issue time. 

The constant delays on the branches from nodes 96 through 
98 represent Bearer travel times to the appropriate warehouse. 

The network associated with match node 74 represents the National 
City driver/messenger. The logic for removing the transaction ( s) 
from Q-node 70 is identical to the Chapter 6 messenger descrip- 
tion. However, this messenger will always be dispatched from 
the timing network and, as shown on the branch from node 73, 
the trip will not be made if there are no IPG Is to take. Since 
the messenger will return from National City with warehouse 
refusals, a portion of them may also experience a longer delay 
than usual. 
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The match node 91 messenger will be arriving from the 
Figure 6-6 node 87 network during the day shift. Since this 
is the regular message service, the trip to the warehouse via 
node 94 will be made regardless of the status of Q-node 78. 

The second shift messenger runs, while less frequent, will in- 
clude all stops made on the day shift. However, they will be 
initiated from a distinct network timing segment to facilitate 
revisions in subsequent versions of the model. For example, 
decision logic to inhibit messenger travel if Q-node 78 were 
empty could be incorporated into the disjoint timing network 
on Figure 10-3. 

The final Figure 7-6 network segment to be discussed is 
the referral statistics summary performed by nodes 65 through 
68. Batch and POE referrals plus warehouse refusals are routed 
to node 65 for a time between referrals computation. The Q- 
GERT analysis Program will provide a histogram of interarrival 
times based upon user defined cell divisions as specified on 
the the STA tistics node 65 input card. Similar histograms for 
Interval statistics will be generated at nodes 66 through 68. 
The branching from node 65 splits the referrals into IPG I 
through III requisitions. Interval statistics refer to the 
time between the last requisition mark time, which is the 
arrival time in the model, and the arrival of the transaction 
at the node effecting the collection of interval statistics. 

Had attribute 3 been used to distinguish between autodin and 
POE demands within each IPG, separate referral statistics could 
have been maintained on each major category. This enhancement 
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would be particularly useful if autodin IPG referrals could 
be isolated during input categorization and assigned a distinct 
attribute value. First, since these transactions have already 
been referred by the POE stock point and rerouted by the ICP, 
the allowable processing time is decreased. Finally, the ICP 
rerouting was initiated based on visibility of the NSC San 
Diego asset position through the TIR (Transaction Item Reporting) 
process. Therefore, a subsequent NSC San Diego referral on 
this type of transaction either indicates a record discrepancy 
or is prompted by the real time lag in the TIR procedure. 

It must be emphasized that the referral statistics collected 
at nodes 65 through 68 were specified by the node input cards 
and represent the most elementary statistics gathering tech- 
nique available in Q-GERT. An entire chapter in reference (a) 
is devoted to the collection of user designated statistics 
by means of program inserts accessing established Q-GERT sub- 
routines. Therefore, the complexity of the statistical output 
is a modeling decision that is not limited to the standard 
statistics node options of First release. All releases, time 
Between releases. Interval times, and Delay from first arriving 
transaction to nodal release. The latter designation would 
be of interest only if transactions were being accumulated 
before being released. 

C. DATA PROCESSING DEPARTMENT KEYPUNCH 

The processing taking place in DPD keypunch is presented 
in Figure 7-7. Requisitions are transported by messenger 
from node 99 on Figure 6-6 to regular node 100. Arriving 
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Figure 7-7. DPD Keypunch 




transactions include SERVMART, Special Programs, Provisions, 

POE IPG II mechanized 1348s, and all POE IPG III demands. 

That is, requisitions from all categories routed to Q-node 
25 on Figure 6-6 are delivered by messenger to node 100 where 
the indicated conditional branching occurs. 

All mechanized input is branched from node 100 to Q-node 
6, the batch processing Q-node from Figure 6-5. Therefore, 
all mechanized input including SERVMART replenishment requisi- 
tions will be processed during the next scheduled batch run 
after their arrival. This treatment of SERVMART replenishments 
is erroneous in that the entire replenishment tape is actually 
processed during the same batch run. However, since SERVMART 
requests will subsequently be delayed a day by Production Planning, 
the overall time in the system will not be increased through 
the multiple batch technique used. As mentioned in Chapter 6, 
it was the choice of a modeling technique through which SERVMART 
replenishments arrive periodically during the day rather than 
all at once that leads to an increased time in the system for 
this demand category. 

Nonmechanized DD 1348s, all Special Program requests, and 
provisions demands are segregated at node 100 and sent to Q- 
nodes 102, 110, and 106, respectively, to await the availa- 
bility of DPD keypunch resources. DD 1348s from Q-node 102 
will be processed in the resource allocation network consisting 
of nodes 103 through 105. As indicated on the RES card image 
above allocate node 103, two type 3 resources designated REGKP 
will be available to keypunch DD 1348s. Similarly, one type 
4 PROVKP resource has been provided to keypunch provisions 
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requests in the nodes 106 through 109 network segment. The 
output symbology on the Special Programs queue, Q-node 110, 
indicates that either resource type 3. or 4 will keypunch these 
requests. However, the POR designator on allocate nodes 103 
and 107 will prohibit the processing of Special Program require- 
ments by either resource type until the respective preferred 
Q-node, 102 or 106, is empty. 

The three keypunch resources specified on Figure 7-7 will 
be active on the day shift only. The indicated modeling approach 
leads to the continuous processing of a particular demand cate- 
gory prior to shifting resources to a different input type. 

A punch- to-disk system featuring the establishment of a dis- 
tinct record content format for each input category is used 
during actual operations. Therefore, once a specific format 
has been established, requests corresponding to that format 
are sequentially keypunched until management, or the absence 
of additional input, mandates a shift to a different input 
type. No attempt has been made to model the management peroga- 
tive mentioned above. However, it is assumed that the approach 
used will permit batch keypunching of Special Program requests 
due to the periodic, vice continuous, arrival of requisitions 
by messenger. 

Reference (b) allotted four DPD keypunch operators. Based 
upon the Appendix C workload summary, an initial allocation of 
three personnel to keypunch and verify has been established. 

The provisioning resource was purposely categorized as a dis- 
tinct resource type to model the special attention that provisions 



actually receive. DPD keypunch resources will be removed for 
a 1.5 day period every other week to model the existing pay- 
roll processing interrupt. This resource removal, as well as 
all other resource altering actions, will be initiated in the 
timing network. It should be noted that a resource allocation 
scheme similar to the issue/receiving example presented earlier 
in this chapter could be used to alter DPD keypunch resources 
based on the volume in Q- nodes 102, 106, and 110. 

After keypunching is completed, Special Program requests, 
both IPG II and III, are routed from free nodes 105 and 109 
to node 111. The delay initiated on the branch leaving node 
111 represents the standard program pricing delay experienced 
by all Special Program transactions. Based upon the limited 
information available to quantify this delay, a normal dis- 
tribution having a mean of 7.5 days, a standard deviation of 
1 day, a minimum of 5 days, and a maximum of 10 days was chosen 
as representative of a pricing cycle that "may take up to 10 
days" to complete. Note that the reference (e) reports indi- 
cated a daily average of approximately 100 IPG II Special Pro- 
gram requests over the five month data base. If that count is 
accurate , the 5-10 day delay experienced by these transactions 
would obviously severely hamper NSC San Diego's efforts to 
meet the IPG II response times specified in reference (d) . 

Keypunched DD 1348s and provisions leave free nodes 105 
and 109, respectively, for input to DPD batch processing. The 
DD 1348s are routed to Q-node 6 on Figure 6-5 where they will 
be processed during the next scheduled batch run. Provisions 



are routed to Q-node 114 on Figure 8-2 and held until the 
next special 1800 batch provisions run occurs. 
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VIII. DATA PROCESSING DEPARTMENT BATCH PROCESSING AND LOTTING 



A. DPD FUNCTIONAL OVERVIEW 

# 

Figure 8-1 summarizes the requisition categories awaiting 
either routine or special batch demand processing in DPD and 
presents a block diagram overview of the events transpiring 
during DPD operations. This figure is not to be interpreted 
as a formal part of the Q-GERT network. It is provided solely 
to facilitate the explanation of the DPD functions prior to 
the introduction of the formal network symbology in Figure 
8-2. Therefore, Q-nodes 112 through 114, which appear for 
the first time in Figure 8-1, will be repeated on Figure 8-2. 

Q-node 6, which may be considered the routine batch pro- 
cessing input queue, and match node 10 are repeated from Figure 
6-5. All requisition categories except QUICK PIC, Provisions, 
and POE IPG II requests put in-process in Customer Services 
await FIFO priority batch processing in Q-node 6. Requisitions 
will be released from Q-node 6 and processed when matching 
transactions from the Figure 6-5 Q-node 11 messenger network 
are generated. As previously mentioned, the routine batch 
processing of Q-node 6 transactions occurs seven times each 
day with the first run scheduled at 0330 and the finale at 2200. 
Nevertheless, the model routine batch processing schedule will 
consist of six runs beginning at 0700 each working day and every 
three hours thereafter. Issues other than IPG I originated by 
the 0330 run will not be processed that same day. Therefore, 
no additional issue delay is being added by the revised schedule. 
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Figure 8-1. DPD Functional Overview 




The number of routine batch runs was reduced to six not only 
to facilitate the network timing, but also to circumvent the 
somewhat enigmatic, and unexplained, scheduling of a 1000 
special batch run right after a routine 0930 effort that pro- 
cesses available POE input along with the autodin traffic. 
Finally, it must be noted that the model schedule can delay 
referrals as much as 3.5 hours by virtue of rescheduling the 
0330 run until 0700. 

The basic functions performed in DPD are demand exception 
generation, material availability determination, and, if avail- 
able, subsequent sorting, lotting, and Production Planning 
manipulation of the issue documents (or issue document image) . 
However, each requisition category is afforded a somewhat 
different processing technique; Figure 8-1 illustrates the 
functions that apply to the various demand categories. 

The SERVMART decision block in the middle of the figure 
functions to exclude this type of transaction from a demand 
exception check in accordance with the rationale presented in 
Chapter 5. Therefore, SERVMART requests join Provisions and 
In-Process demands leaving Q-nodes 114 and 113 in the block 
designated availability check. The omission of a demand 
exception check for Provisions was also discussed in Chapter 
5. In-Process transactions have already been checked for 
exceptions during Customer Services processing (Figure 7-5) . 

Although it is not shown on the overview, requisitions 
having a demand exception will be routed to the exception 
processing unit in Customer Services where QUICK PICs exceptions 



will be given expedited processing at Q-node 50 (Figure 7-5) . 

All other batch exceptions will be given routine, but priori- 
tized, processing at Q-node 49. The detailed network symbology 
for demand exception generation is presented in Figure 8-2. 

All transactions are shown being checked for availability 
on Figure 8-1. However, the availability block is subdivided 
into three distinct applicable rates. SERVMART and Provisions 
are assumed to encounter a net availability rate. In general, 
SERVMART material is backed-up by main supply stock in accordance 
with standard SERVMART operating procedures. There are excep- 
tions to this policy, but the model assumption specifies a 
100% back-up. Similarly, Provisions requests are generally 
submitted on partially completed DD 1348s that are prepunched 
by NSC San Diego. Therefore, the model assumption is that the 
prepunched requisitions apply to carried material only. All 
remaining demand categories except In-Process transactions will 
be referred at the 32% NIS/NC (gross) rate used in Customer 
Services on Figure 7-5 . 

Demands put in-process in Customer Services are shown enter- 
ing the section of the availability block labeled probabilistic. 
This designation was chosen to indicate that the assets that 
were available when the transaction was put in-process may no 
longer exist. The in-process quantity for a particular line 
item may exceed the number of units on-hand at the 1800 release 
of these transactions. It was noted that transactions are 
put in-process based solely on the on-hand quantity in file; 
i.e., there is no visibility of any quantity already placed 
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in-process. Furthermore, the asset position upon which the 
in-process decision was based may have changed due either to 
the receipt of additional material or the reservation of 
assets during batch processing. The latter event, of course, 
is most relevant for attempting to determine whether sufficient 
material remains available to satisfy the in-process quantity. 
Unfortunately, any attempt to estimate a reasonably accurate 
availability rate for the in-process release procedure would 
require a line item, vice system, analysis that is well beyond 
the scope of this study. Therefore, having emphasized both 
the analytical complexity of the process and, more importantly, 
the impact of the current processing technique on IPG II 
availability and issue time, the problem will conveniently be 
ignored by the model. It will be assumed that assets are still 
available for in-process transactions and, as illustrated on 
Figure 8-2, these requests will not be subjected to an availa- 
bility check at the time of release. 

The functions appearing on Figure 8-1 after the availability 
check may be regarded as occurring once each day on the midnight 
shift and serving to create and arrange the issue documents 
that will be processed the next morning. Provisions and QUICK 
PIC requests are batch processed during special runs at 1800 
and 0100, respectively. The issue documents for these categories 
are subsequently sorted by location and forwarded to the appro- 
priate warehouse for issue. Other IPG III requests including 
SERVMART replenishments are entered in a Production Planning 
Holding File and delayed for one working day. This procedure 
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was instituted in recognition of holding area space constraints. 
It proves much jore efficient to program an unavoidable 24 
hour delay as a filed issue document image rather than an 
actual material issue backlog in the warehouse and delivery 
staging areas. 

IPG Ills that have completed the programmed delay and the 
remainder of the non-QUICK PIC IPG IIs are shown entering the 
lotting block on Figure 8-1. The lotting procedure is a com- 
plex process that functions to establish the issuing sequence 
for the total transaction input. Some, but by no means all, 
of the lotting and issue procedures currently in effect at 
NSC San Diego may be summarized in the following manner: 

. The sorted QUICK PIC transactions are the first issues 
processed at the beginning of the work day. 

. All other IPG II issue documents are lotted together 
in the next LOT(s) and represent the first new material 
issued after QUICK PIC. 

. Any backlogged issues from the previous day's LOTs 
are completed prior to issuing the new LOT 1 IPG IIs. 

. SERVMART replenishments are a separate LOT and are 
issued after IPG II transactions have been processed. 

. Discussions of LOTs and LOT sizes apply principally to 
the processing of binnable issues by AMHS . The esti- 
mated percentage of AMHS issues will be 65%? i.e., 

AMHS issues at the Broadway complex represent 65% of 
all NSC San Diego non-Provisions issues. 
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AMHS accumulator line and packing line decisions implied 
or made by the lotting program are based on the number 
of requisitions per customer within each distinct IPG 
LOT. 

The LP and SP packing lines are generally used for 
large (greater than 124 line items) customers. 

The parcel post packing line is generally used for small 
(less than 5 line items) customers. 

The OP packing line is the "free flow" line along which 
all non-Bearer IPG I material is routed. 

The remaining ten packing lines receive material lotted 
for customers to whom greater than four but less than 
125 line items are being issued. The ten AMHS accumu- 
lator lines, which are released one at a time, route 
material to the ten packing lines. A maximum of ten 
customers per accumulator line is permitted. 

A LOT is considered complete when the 10 accumulator 
lines plus the LP and SP lines are "filled" by the 
lotting program logic. Therefore, if the first LOT 
does not cover all the IPG II requisitions that must 
be issued, then the second LOT will also contain only 
IPG II issue documents. Similarly, two or three LOTs 
may be necessary to effect the issue and subsequent 
packing/consolidating of all IPG III transactions. 
Referencing a UIC locator/address file, the lotting pro- 
gram assigns a local delivery zone or indicates that 
shipping is required on the issue document. 
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. The lotting program attempts to equalize the workload 
represented by each accumulator line over the total 
number of L'OTs each day. 

No attempt will be made to duplicate the logic associated 
with the lotting program. The basic issue processing sequence 
described above will be followed, but no customer-related deci- 
sion logic will be included in the model. The simulation of 
the packing function, which will be described in Chapter 9, 
will be greatly simplified based on the aforementioned equalized 
packing line workload characteristic of the lotting program. 

A brief comment on Production Planning should be made before 
concluding the discussion of Figure 8-1. The model only recog- 
nizes the 24 hour Production Planning delay of selected IPG 
III issues. In actuality, the process is much more complex. 
Additional functions include the holding of issue documents for 
deployed ships and an effective backlog management routine that 
considers daily workload and local delivery schedules during 
the time-phased release of backlogged IPG III issues. This 
program, which was successfully operated in the past, has not 
been used recently due to a decreased operating tempo and other 
considerations . 

B. DPD Q-GERT SYMBOLOGY 

Figure 8-2 depicts the Q-GERT representation of the DPD 
demand processing, sorting. Production Planning, and lotting 
functions. Transactions to be processed arrive at Q-nodes 112 
through 114 and regular node 115, which is in the routine batch 
processing stream that is initiated six times daily on Figure 
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6-5. As described below, each network category will be pro- 
cessed through the network logic on the upper portion of 
Figure 8-2 and, where appropriate, result in a demand excep- 
tion, a referral, or occupancy in Q-node 126 for sorting and/ 
or lotting on the midnight shift. 

The contents of Q-node 6 on Figure 6-5 will be routed to 
regular node 115 via match node 10 six times each working day. 
The conditional branching at node 115 routes all non-SERVMART 
demands to node 119 for a demand exception check. The delay 
of 0.0001 hours on many of the Figure 8-2 branches is an arbi- 
trarily chosen processing time that permits the handling of 
10,000 transactions per hour, a figure that is well above the 
expected daily demand. Exceptions will occur at node 119 at 
the normal 6.2% rate and, since QUICK PIC does not arrive at 
node 119 through node 115, routine batch exceptions (A3.NE.3) 
will be routed from node 120 to Q-node 49 on Figure 7-5 for 
exception processing. If no exception is encountered, the 
standard gross availability check is made at node 127 with 
referrals being routed to node 65 on Figure 7-6 and potential 
issues to node 128. The conditional branching at node 128 
functions to isolate IPG Ills - SERVMARTs , Provisions, and 
In-Process Ills are excluded - in order to assess the 24 hour 
Production Planning delay prior to their entry into the Sort/ 

LOT queue. IPG II transactions are routed directly to Q-node 
126 to await lotting in a "smallest value of attribute 3" pri- 
ority. All transactions processed in DPD are eventually sub- 
jected to the Q-node 126 ranking procedure. Therefore, inasmuch 
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Figure 8-2. Data Processing Department 



as IPH I requests (A3 = 1 or 2) will theoretically never be 
routed to this network segment, the first transactions in 
Q-node 126 at the time of lotting should be QUICK PIC demands. 

The SERVMART transactions that were isolated at node 115 
undergo a different processing procedure. First, their attri- 
bute 3 value is changed to 4.5 at node 129 to ensure position- 
ing in Q-node 126 ahead of all other IPG III requests. Follow- 
ing the attribute reassignment, they are afforded an availa- 
bility check equal to the NSC San Diego all cog net value of 
83.4% and either routed to node 65 on Figure 7-6 for the collec- 
tion of statistics on referrals or forwarded to node 125 where, 
once isolated again on the lower branch, they are routinely 
delayed for the standard 24 hours. 

Having completed the discussion of the routing of routine 
batch input arriving via node 115, the QUICK PIC network seg- 
ment beginning at Q-node 112 must be considered. Transactions 
shown arriving from nodes 41 and 46 on Figure 7-5 will not 
appear in Q-node 112 until after 1800 on each working day; 
the Customer Services QUICK PIC delay network precludes pro- 
cessing until that time. Since QUICK PIC requests are processed 
during a special 0100 run, no resources will be made available 
at allocate node 116 until that time. The initial allocation 
of 1 type 5 resource shown on the RES card above the allocate 
node was provided to comply with the Q-GERT requirement for an 
initial capacity greater than zero; this resource will immediately 
be removed in the Chapter 10 timing network and reapplied at 
0100 on the appropriate days to accomplish the sequential 
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processing of QUICK PIC transactions in Q-node 112. The 
processing rate will be 10,000 per hour as shown on the branch 
between nodes 117 and 118, the free node. The QUICK PIC trans- 
actions are routed to the node 119 standard demand exception 
check and, provided an exception occurs, routed by the node 
120 upper branch to the head of the queue at Q-node 50 on 
Figure 7-5 to ensure QUICK PIC exceptions receive expedited 
processing the next working day. If no exception occurs, QUICK 
PICs are routed through the same availability check and IPG 
III delay network-nodes 127 and 128 - that routine batch 
transactions encounter and theoretically become positioned at 
the head of Q-node 126. 

The special Provisions run and the daily release of In- 
Process demands both occur at 1800. The network resource logic 
associated with Q-nodes 114 and 113 functions to arbitrarily 
give Provisions priority; Q-node 114 will be emptied before 
any transactions in Q-node 113 are processed. The resource 
scheme at allocate node 121 is similar to the QUICK PIC logic. 

The initial resource 6 capacity of 1 will immediately be altered 
to zero in the timing network. It will be reapplied at 1800 
and transactions in Q-nodes 114 and 113 will be processed at 
a rate of 10,000 per hour. Both this resource and the QUICK 
PIC type 5 resource will remain available for a half hour. The 
Customer Services keypunch resource will be removed from 1800 
to 1830 to prohibit the arrival of In-Process transactions during 
this admittedly extended period. This technique represents a 
more convenient modeling approach than a repetitive sampling 
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of Q-node contents from the timing network. The conditional 
branching at free node 123 routes Provisions documents to 
node 124 for a net availability check, delays the IPG III 
In-Process transactions 24 hours before entry to Q-node 126, 
and routes IPG II In-Process demands directly to the Sort/ 

LOT queue for same night processing. Therefore, neither Pro- 
visions nor In-Process demands are given a demand exception 
check for reasons previously discussed. Furthermore, In- 
Process transactions are assumed to still be available and 
Provisions are considered available at the same net rate applied 
to SERVMART . This latter assumption could be made more realistic 
by using the availability rate for Provisions cogs only, but 
this degree of accuracy is not considered essential for this 
model. Provisions requests leaving node 124 are either referred 
through the branch to node 65 on Figure 7-6 or forwarded to 
node 125 where they are conditionally isolated and sent without 
delay to Q-node 126 to await lotting later that night. 

The network segment beginning with allocate node 130 at the 
bottom of Figure 8-2 accomplishes as much of the actual lotting 
procedure as can conveniently be displayed in DPD . In particu- 
lar, with the actual LOTs already determined by the ranking 
structure in Q-node 126, the sequential processing network 
beginning with node 130 serves solely to effect a warehouse 
distribution followed by the assignment of the appropriate issue 
time for that location. Since it's beyond the scope of this 
project to consider individual customer location (shipping or 
local delivery) and percentage of demand, numerous simplifying 
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assumptions regarding packing categories and shipping percen- 
tages will be made in Chapter 9. This procedure obviously 
deviates from the lotting explanation provided earlier in this 
chapter . 

After initially being altered to zero, the single type 7 
resource will be provided at allocate node 130 at 0300 and 
removed at 0500. Unless there are more than 20,000 transac- 
tions waiting in Q-node 126, which is highly unlikely, the 
two hours will be sufficient to empty the Sort/LOT queue. At 
free node 132 all Provisions requests are branched directly 
to node 135 for a National City issue time assignment to 
attribute 5, then sent to node 138 to be isolated once again 
and forwarded to a specific National City queue. All other 
National City issues arriving at node 138 are forwarded to a 
different queue to distinguish them from the Provisions demands 
in the issue processing priority scheme shown in Chapter 9, 

The middle branch from node 132 routes SERVMART requests to 
node 133 for the indicated probabilistic division into Broadway 
and National City issues, the assignment of appropriate issue 
times, and further routing as shown. The bottom branch from 
free node 132 to node 139, which routes all transactions other 

than SERVMART and Provisions, permits a "precautionary check" 

* 

for IPG I transactions at node 139 prior to the indicated 
routing to node 134 for the standard non-Provisions issue branch- 
ing of 65% Broadway bin, 20% Broadway bulk, and 15% National 
City that was first encountered on Figure 7-6. The bottom 
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branch from node 139 routes IPG Is that have inadvertently 
been subjected to DPD processing back to the IPG I processing 
stream on Figure 7-5. As a final comment, it should be noted 
that the Broadway bin issue time of 0.045 hours assigned at 
node 136 is significantly less than the 0.068 hours allotted 
to IPG Is at node 77 on Figure 7-6. The difference lies in 
the faster sequential processing of lotted bin issues using 
the AMHS capability in lieu of the IPG I unsequenced hotline 
issue procedure that acts as an interrupt to ongoing processing. 
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IX. ISSUE, PACKING; MARKING, AND LOCAL DELIVERY 



A. DATA CONSIDERATIONS 

The Broadway and* National City issue, packing, and marking 
functions and the local delivery system are presented on Figures 
9-1 through 9-4. Distinct network segments are provided for 
Broadway bin, Broadway bulk, and National City. The system 
displayed generally approximates operating procedures in effect 
in May 1980. However, procedural changes within the next few 
months are a virtual certainty. Therefore, the contemplated 
revisions are discussed in the last section of this chapter. 

The processing times as well as the percentage estimates 
dictating the numerous probabilistic branches used in the model 
are of dubious validity. The DIMES issue times assigned to 
the transactions on Figure 8-2 were not disputed. However, 
both the Broadway and National City packing supervisors took 
exception to the packing standards established by the DIMES 
study and used in the reference (b) simulation. Therefore, 
revised standards based upon the supervisor’s estimates were 
used fro packing and marking. Having observed the bulk packing 
operation, it appears much more realistic to use the updated 
version. The DIMES standard of 8.5 bulk light packs per hour is 
not nearly as realistic as the 2.15 line items/hour used to 
gauge the National City packers' performance. Marking times 
for bulk material going to shipping were also revised to reflect 
10.5 line items per hour, or .095 hours per item, vice the 
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variable marking time scheme used in reference (b) . Marking 
light and heavy packs is identical except for the size of 
the container being marked. 

The difficulty in developing accurate branching percentage 
stems from the lack of line item work measurement statistics 
in the Material Department. Due to the degree of consolidation 
occurring in the packing process and the excessive bulk of 
much of the material that must be processed, the predominant 
work unit becomes measurement tons. Therefore, although 
information such as the number of measurement tons packed or 
sent to shipping is readily available, the percentage of line 
items receiving a particular kind of pack or requiring shipping 
remains a crude estimate at best. The same rationale applies 
to the distinction between light and heavy pack; the decision 
is based upon the volume of the container that must be processed. 
Neither line item volume nor a completely accurate representa- 
tion of the impact of line item consolidation can be modeled. 

In fact, the effects of consolidation on bulk material are 
deliberately ignored during initial model formulation. Every 
bulk line item routed to packing at Broadway or National City 
is assigned a pack time. The rationale for this decision is 
presented during discussion of relevant Q-GERT network segments. 
Consolidation is a major factor in binnable item processing, 
however, and a detailed discussion of this concept is included 
in Section 9C. 

Finally, the issue documents generated during the lotting 
process are picked up each morning and distributed to the 
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appropriate warehouse by the beginning of the day shift. The 
model does not simulate that messenger service. Transactions 
leaving DPD are routed directly to the appropriate issue queue. 
This technique introduces no error into the model . Although 
the transactions arrive at the Q-nodes prematurely, no resources 
are made available to process them until the day shift commences. 

B. BROADWAY BULK MATERIAL PROCESSING 

The complete Broadway bulk issue, packing, and marking 
process is displayed on Figure 9-1. The bulk input is shown 
arriving at Q-nodes 142 and 143 in the upper left portion of 
the figure. Q-node 142 contains only IPG I issue documents. 
3earers arrive via node 97 from Figure 7-6 and, by virtue of 
an attribute 3 value of 1, assume a position at the head of 
the S/3 (smallest value of attribute 3) queue. The other IPG 
I issue documents, which are transported by messenger from node 
92 on Figure 7-6, are routed to the queue from node 141. The 
conditional branching at that node separates the bulk issues 
from the bin issues that are carried to a different location 
by the same messenger. The 0.2 hour delay on the branch between 
nodes 141 and 142 is additive to the 0.4 hour document delay 
on Figure 7-6 and models the depositing of bin IPG I issue 
documents 0.2 of an hour before the bulk DD 1348-ls. The 
lotted output of Broadway bulk material, which contains only 
IPH II and III issues, is shown entering Q-node 143 from node 
137 on Figure 8-2. Although a given day's lotting output will 
arrive at node 143 in IPG sequence, the F (First-In-First-Out) 
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ranking procedure will ensure that backlogged issues are 
processed before the higher priority transactions lotted 
the following day. Of course, IPG Is will always take prece- 
dence through being routed to the preferred queue, Q-node 142. 

Nodes 144 though 146 represent the resource allocation 
network that performs the bulk issue. The RES card image above 
allocate node 144 indicates that 27 warehousemen are available 
each working day to make bulk issues . The RES card also indi- 
cates that this type 9 resource may only be allocated at node 
144. The issue processing time, which was assigned as attri- 
bute 5 on Figures 7-6 and 8-2, is shown on the branch between 
node 145 and free node 146. Note that the free node has no 
allocate scheme beneath it. Therefore, the RES card order, 
node 144 only, prevails. In fact, throughout this chapter 
resources will generally be associated with a single allocate 
node and changes in capacity or the shifting of resources will 
have to be accomplished either through changes to the RES 
card(s) or alteration schemes similar to the issue/receipt 
example presented in Chapter 7. One type 9 resource will 
remain available for the second shift to ensure that IPG Is 
are processed. However, since the contents of Q-node 143 
are also processed by the same resource, lower IPG backlog 
will also be issued and subsequently packed and/or marked 
during the evening shift. Similarly, an issue and packing 
resource will remain at Broadway bin and National City to 
guarantee that IPG Is are afforded the necessary expeditious 
treatment. The issue backlog processing feature at all three 
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locations is not representative of actual operations. A 
Broadway issuer and packer are available for IPG I processing 
throughout the Broadway complex and backlog management as 
time permits. Modeling that procedure would require either 
distinct resource categorizations and allocate nodes for IPG 
I processors (see AMHS packing on Figure 9-2) or a separate 
evening shift model that would replace the existing network 
segments at 1600. Such complexity was not considered necessary. 
The network presented represents a satisfactory starting point. 

If initial runs yield a high percentage of idle resources, 
there are numerous alternatives that could be evaluated. For 
example, simulation time could be used to compute the shift 
on which an IPG I arrives and effect a routing to a special 
queue for second shift processing. This approach would be 
used in place of the retention of a second shift resource and 
eliminate the processing of lower priority backlog by focusing 
only on IPG Is after 1600. 

After the resource is freed at node 146, the probabilistic 
branching designed to model warehouse refusals is encountered. 

The 1% branch leaving node 146 serves to route warehouse refusals 
to Q-node 154 where they await the arrival of the messenger 
from node 94 on Figure 7-6. The messenger network modeled by 
nodes 152 through 158 is basically identical to the similar 
segment described in detail in Chapter 5. The second input 
into Q-node 154 represents Broadway bin warehouse refusals. 
Although they are picked up at a different location, it is 
assumed that they accompany the messenger on the 0.2 hour 
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journey from the bin area to the bulk warehouse. Therefore, 
a single queue representation of warehouse refusal routing to 
Customer Services node 50 is realistic. Two differences from 
the Chapter 6 netwQrk segment are worthy of mention: (1) the 

warehouse refusals are assigned an attribute 3 value of 0 at 
node 157 to establish processing priorities on Figure 7-5; 
and (2) the messenger is not routed from node 158 since this 
network segment represents the last stop on his modeled run 
and each run is initiated from the timing network. Therefore, 
the messenger run time totals 1.9 hours consisting of 0.5 hours 
on Figure 6-5 (node 85), 0.8 hours on Figure 6-6 (node 87), 
and 0.6 hours on Figure 7-6 (node 94). The document delay of 
0.4 hours leaving node 92 on Figure 7-6 represents travel time 
to the Broadway bin issue area. An additional 0.2 hours is 
assessed bulk issues on Figure 9-1. 

The transactions routed along the upper branch leaving 
node 146 represent material issues. At node 159 Bearers are 
removed from the system as completed issues and routed to 
Figure 9-4 for issue statistics formulation; NSC San Diego 
has no further processing responsibility for Bearers once the 
material has been turned over to the representative of the 
requesting activity. However, bulk issues for both SERVMART 
and QUICK PIC transactions are also factored out as completed 
issues at node 159. QUICK PICs are isolated for transportation 
to the National City designated customer pick-up point. It 
was not considered necessary to model that segment of the 
QUICK PIC procedure. The statistics collected on Figure 9-4 
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are just as meaningful without the travel time to National 
City. SERVMART transactions are removed and sent to SERVMART 
Central Receiving where they undergo further processing to 
ensure compatability with the EPOS inventory system. The 
same procedure is followed for Broadway bin SERVMART issues. 
However, National City SERVMART issues, which constitute only 
5% of the total, are staged in local delivery and transported 
to the appropriate zone as shown on Figure 9-3. The bottom 
branch leaving node 159 directs all other transactions to 
node 161 in the lower left portion of the figure. 

The shipping/local delivery probabilistic branching occurs 
at node 161 with 80% of the transactions designated local 
delivery and routed to node 199 where IPG Is (non-Beareres ) 
are terminated. Admittedly, indicating an issue completion at 
that juncture appears premature. However, local delivery IPG 
Is are not staged to await scheduled zone transportation; nor 
are they routed through any packing or marking evolutions. 

They are, however, considered individually and delivered by 
the most expedient available method. A more sophisticated 
study might consider the time of day and next scheduled delivery 
to the designated zone to facilitate the assignment of a more 
realistic issue completion time. However, meeting IPG I time 
frames has not been a problem at NSC San Diego. Therefore, 
only the standard two hour delay assigned as representative 
of the time between trips to local delivery staging has been 
acknowledged in the model. The similar delay for IPG II and 
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Ill local delivery material is shown on Figure 9-2 immediately 
preceding the bottom branch into node 191. The bypassing of 
packing and marking for local delivery bulk will apply to 
National City material as well. Only bulk material destined 
for shipping will undergo the packing evolution. 

Broadway bulk material to be shipped represents 20% of 
the output from node 161. After being delayed one hour to 
roughly model transportation to the packing area, material to 
be packed arrives at node 198 where IPG Is are segregated and 
sent to Q-node 162 to ensure they receive preferred order 
processing by the resources allocated at node 164. Material 
that has been allotted type 11 resources is probabilistically 
routed to node 166 (40%), node 167 (35%), or node 200 (25%) for 
an attribute 6 assignment representing the indicated category 
of pack plus mark time. The type 11 resource capacity includes 
packers plus markers although the functions are generally per- 
formed independently with marking as a separate station follow- 
ing packing. However, since marking backlogs are a rarity, 
a first pass should be attempted with the functions combined. 
Since there is no mark standard associated with parcel post 
and light pack is marked approximately five times as fast as 
it's packed, a distinct marking resource would be idle over 
95% of the time. A separate resource allocation network for 
the marking function can always be added between free node 
169 - revised to provide a conditional branching that sends 
only light and heavy pack to marking - and the branching to 
issue statistics collection. The conditional branching from 
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node 169 on Figure 9-1 segregates IPG I material from all 
other categories and effectively completes the issue of packed 
and marked material sent to shipping. The packing and marking 
standards applicable to Broadway bulk are included on Figure 
9-1 for ease of reference. 

The branching from node 169 to the Figure 9-4 statistics 
collection network represents the completion of requisition 
processing by the model for items destined for shipping. 

However, the time being measured must not be interpreted as 
representative of the complete requisition processing sequence 
at NSC San Diego. Items exiting node 169 actually are staged 
for periodic delivery to shipping, which is located in National 
City. The subsequent events occurring in shipping constitute 
a requisition response time segment called Transportation Hold 
Time. This period, which includes functions such as selection 
of a shipping mode and consolidation of IPG III material for 
specific transportation categories, will not be modeled during 
this study. Therefore, the statistics collected for material 
sent to shipping are an estimate of the response time segment 
called Storage Site Processing Time. Of course, the model 
could be expanded to include the shipping function and trans- 
actions leaving node 169, and similar nodes on Figures 9-2 and 
9-3, could be routed for additional processing. The model’s 
treatment of local delivery material includes the Transportation 
Hold segment. 
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C. BROADWAY BIN MATERIAL PROCESSING 



Bin material processing is illustrated on Figures 9-1 and 
9-2. The routing through the bin issue process on Figure 9-1 
is basically identical to the Broadway bulk issue process. 

IPG Is are routed to node 147 and all batch transactions are 
shown arriving from node 136 on Figure 8-2. The resource 
allocation network consisting of nodes 149 through 151 pro- 
cesses the contents of Q-node 147 (IPG Is) before transactions 
in node 148. The issue time is again the transaction attribute 
5 value, which was assigned during the lotting procedure in 
Chapter 8 or on Figure 7-6 for IPG I requests. The FIFO ranking 
in Q-node 148 will ensure that backlog is processed before 
newly lotted transactions. Warehouse refusals are originated 
at free node 151 and routed to the messenger network described 
in the Broadway bulk discussion. Finally, QUICK PIC, SERVMART , 
and Bearer issues depart the system at node 160. The rationale 
for this decision was also presented in the discussion of bulk 
issues . 

A few additional comments on the bin issue time are appro- 
priate. First, IPG I issues, which represent an interrupt 
to sequential location processing, are assigned a larger 
issue time than lotted transactions. Secondly, the lotted line 
item issue time, while being lower than the IPG I value, includes 
an average UIC sort time. Lotted material is picked in loca- 
tion sequence then manually consolidated by UIC on a spar line 
before the tote pans holding the binnable material are forwarded 



130 



to packing via the AMHS accumulator lines. An awareness of 
this procedure is crucial to the discussion of the several 
posed procedural changes presented at the end of this section. 
Finally, consideration was given to assigning the higher IPG 
I issue time to QUICK PIC transactions. Their relatively low 
volume would appear to negate the benefits of the location sort 
they are given; i.e., there would still be a considerable dis- 
tance between locations. However, since they are not subjected 
to the UIC sort that is included in the AMHS bin issue time, 
it was concluded that the faster time was more representative. 

The remaining transactions departing node 160 are routed 
to node 171 on Figure 9-2 for IPG I segregation and application 
to the bin packing and marking network beginning with Q-nodes 
172 and 179. At this juncture the current bin processing pro- 
cedure differs from the bulk branching logic? all bin material, 
destined for both local delivery and shipping, goes through 
packing. Therefore, a probabilistic branch analagous to the 
node 161 (Figure 9-1) routing to local delivery is not required 
for bin material. All remaining IPG Is are branched to Q-node 
172 on Figure 9-2 and all other transactions are routed to 
Q-node 179. 

The Broadway bin packing and marking network contains two 
distinct resource types. The solitary type 12 resource allo- 
cated only at node 173 models the OP line along which all IPG 
Is are routed. This resource will remain available on the 
evening shift. However, since reallocation occurs only to 
node 173, the lower priority bin backlog in Q-node 179 will 
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Figure 9-2. Broadway Bin Pack/Mark and Local Delivery Staging 





not be packed and marked during the second shift. It was 
considered necessary to associate a distinct allocate node 
with IPG I transactions. Using the bulk packing procedure 
of a simple allocate node, 14 resources, and the IPG I queue 
designated as preferred would lead to situations where all 
14 packers were processing IPG Is. Such an occurrence would 
be a complete distortion of reality; each of the 14 packers 
is assigned to a specific packing line and the lotting program 
attempts to equalize workload along 10 of these lines at least. 
The large customer lines, SP and LP, and the Parcel Post line 
receive material based on specific criteria that preclude work- 
load equalization. Consideration was given to having the IPG 
I resource work secondarily on the contents of Q-node 179 in 
a manner similar to the Q-node 110 relationship to allocate 
node 103 on Figure 7-7 (envision a second dashed line originated 
at Q-node 179 and terminated at allocate node 173) . This idea 
was discarded based on a reluctance to apply IPG I material 
for binnable items will theoretically be packed on a line item 
basis most of the time. Therefore, the packing times assigned 
should require little or no adjustment to incorporate the 
effects of packing numerous line items for the same customer 
in the same container. On the other hand, the material on 
every other line but Parcel Post is grouped by UIC and is 
afforded a packing standard that differs from the time associated 
with individual line item packing. Therefore, no attempt was 
made to model the IPG I packers involvement with material on 
other lines when Q-node 173 is empty. However, providing an 
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example of how such a procedure could be modeled will illus- 
trate a useful method of using dissimilar resources to perform 
the same function. 

The single digit numbers in the network above were added 
to the Figure 9-2 decision logic and free node 190 was modi- 
fied to release either type 12 or 13 resources based on the 
attribute 7 value of the arriving transaction. All transactions 
arriving at node 3 from Q-node 179 will use type 13 resources. 
Therefore, an attribute 7 value of 13 is assigned to all trans- 
actions that are allocated resources by node 180. Allocate 
node 173, however, is modeled to enable processing of transac- 
tions from Q-node 179 must be subjected to the branching deci- 
sions beginning at node 182. Therefore, for an IPG II or III 
item, the lower branch is taken from node 1 and an attribute 
7 value of 12 is assigned at node 2 before the transaction is 
processed at node 182 and beyond. Arrival of the transaction 
at free node 190 will then result in the correct type of re- 
source being released. The objective of this example was to 
illustrate that free nodes need not be restrictive in the type 
of resources that they may release. It should be noted that 
free nodes such as 178 and 190 on Figure 9-2 will release 
only the designated type 12 and 13 resources, respectively. 

Prior to completing the discussion of the Figure 9-2 net- 
work segment, the issue of consolidation and the rationale 
for the packing standards used for bin material must be 
addressed. The consolidation standard used in reference (b) , 
which appears to have been applied to both bin and bulk items. 
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was 3.46 L/I (line items) per pack. This consolidation factor 
was used in conjunction with DIMES packing standards which, 
based on more recent observed production rates, appear to be 
.too low. There is some bulk consolidation undertaken at National 
City, particularly with IPG III material. Nevertheless, a 
3.46 L/I per pack average is considered too high to be repre- 
sentative of actual National City operations. A higher degree 
of consolidation is realized for Broadway bulk material and, 
consequently, the 3.46 average may be realistic. If initial 
simulation runs create excessive backlogs using the Figure 9-1 
individual line item bulk packing procedure, then the consoli- 
dation feature can be modeled by creating a new mark plus pack 
time equal to the current value divided by the average number 
of line items per pack. It would appear prudent to initially 
simulate with a few values somewhat lower than 3.46. 

The Broadway bin consolidation factor is assuredly higher 
than the 3.46 L/I value. Twelve of the fourteen packing lines 
theoretically receive material grouped by UIC with at least 
five line items per customer. It follows that the majority 
of the material on these 12 lines would be consolidated at a 
rate of at least five line items per pack. In fact, two of 
these twelve lines, LP and SP, will often contain over 200 
line items for the same customer. Therefore, a consolidation 
factor limited only by the size of the container and/or subse- 
quent transportation weight or volume constraints will apply. 

In view of the emphasis on consolidated packing of binnables, 
an admittedly rough approach for incorporating consolidation 
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into the initial model was developed and is presented during 
the discussion of the actual standards below. 

The bin material packing categories may be summarized 
and modified in the following manner: 



CATEGORY 


PACK/HR 


STANDARD 

HR/PACK 


MODELED 
L/I PER PACK 


STANDARS 
HR/LINE ITEM 


Parcel Post 


12.42/hr. 


0.08 


1 


0.08 


Rough Pack 
(Local Delivery) 


14.59/hr. 


0.068 


7.6 


0.009 


Light Pack 
(Shipping) 


2.15/hr. 


0.465 


7.6 


0.07 


Heavy Pack 
(Shipping) 


0.7/hr. 


1.43 


15.2 


0.103 


Column three is 


simply the 


reciprocal 


of column two, 


. It is 



displayed to provide a correlation with the processing time 
value assignments that are entered on the relevant network 
figures in terms of "standard" hours. The pack/hour standards 
were supplied by the NSC San Diego packing supervisors at 
Broadway and National City. Excluding IPG Is on the OP line 
and material on the parcel post line, all Broadway bin material 
can be viewed as receiving an initial rough pack consisting 
of the placing of all material for a particular UIC in a large 
container (s) . Local delivery material would then receive 
negligible additional packing time and a relatively fast mark- 
ing process. To the contrary, rough packed material destined 
for shipping would encounter significant additional packing 
time. The container would receive a light pack if its volume 
were less than 20 cubic feet or a heavy pack if larger. 
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The modeled L/I per pack values in column 4 were computed 
based upon the following assumptions: (1) the column two 

pack/hour is accurate; and (2) an arbitrary time of 0.5 minutes, 
or 0.009 standard hours as shown in the last column for rough 
pack, is needed to physically verify the UIC on a binnable 
item and place it in the appropriate container. Consequently, 
since it takes 0.068 hours to complete one rough pack, there 
are 7.6 L/I (0.068 0.009) in each rough pack. The heavy 

pack modeled L/I per pack was arbitrarily set to twice the 
light pack value in recognition of the larger volume. 

The standard hours/line item for material sent to shipping 
will be larger to reflect the actual packing evolution after 
the indicated number of line items are containerized. For 
the purposes of the initial runs of this model, the entire 
column three standard hour per pack value will be divided among 
the indicated number of line items per pack. Therefore, a 
light pack line item will be assessed an initial 0.009 hours 
plus its share of the 0.465 hours per light pack. The light 
pack hour per line item becomes 0.009 hours plus 0.465 -7 7 .6 
hours, or 0.009 plus .061, which is 0.07 hours. Based on the 
results of initial simulations, the modeler may wish to reduce 
the additional light pack assessment per line item to cover 
only the difference between the 0.465 hour per pack and the 
containerization time (0.009 x 7.6) . Using this approach, 0.397 
hours of light pack time, or 0.052 hours per line item, would 
be allocated across 7.6 line items. Then a total pack time 
of the standard 0.465 hours consisting of containerization 
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time (0.009 * 7.6) plus light pack time (0.052 x 7.6) would be 
realized. The technique currently used yields a total light 
pack time of 0.532 hours because the containerization time 
is additive to the total standard pack time. 

The heavy pack time per line item is computed in a simi- 
lar manner with the entire 1.43 hours per pack spread across 
the 15.2 line items per pack. Therefore, each line item will 
receive a 0.009 containerization time plus a 0.094 hour (1.43 
t 15.2) additive heavy pack time for a total of 0.103 hours. 
Once again the total heavy pack time will exceed the column 
three standard by the amount of time necessary to containerize 
the 15.2 line items. 

The mark time standard of 10.5 packs per hour, or 0.095 
hours, will also be distributed across the modeled line items 
per pack for items going to shipping. 

Packing estimates in general, and this attempt to model 
the impact of binnable consolidation in particular, must be 
scrutinized, evaluated, and revised as needed. Although the 
rough pack standard is probably relatively accurate, the light 
and heavy pack estimates contain a significant amount of varia- 
bility. Bulk packing estimates, which initially contain no 
consolidation feature, are exceptionally variable; the values 
specified represent an average of pack times that occasionally 
exceed eight hours. 

To summarize, bulk material packing times are not adjusted 
for the impact of consolidation; items to be shipped are packed 
on a line item basis and local delivery bulk material bypasses 
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packing. Unrealistic bulk packing backlogs encountered in 
early simulation runs should first be addressed by incorporating 
a consolidation factor similar to the binnable approach. The 
binnable packing model, which is explained on a node-by-node 
basis below, represents the most reasonable initial approach 
available given the paucity of line item data. It should be 
emphasized that the accumulation technique described in Chapter 
4 could be used to great advantage in any consolidation scheme 
if it were not necessary to maintain line item visibility. 
However, line item tracking is necessary for the computation 
of relevant processing statistics. The accumulation method 
is therefore unacceptable. 

Returning to Figure 9-2, consider the network segment de- 
voted to the packing and marking of the IPG I material residing 
in Q-node 172. When the solitary IPG packing resource becomes 
available, one IPG I binnable line item is released from Q-node 
172 and subjected to the probabilistic branching at node 174. 

If the item must be shipped to a remote customer, the indicated 
0.08 mark plus pack time is assigned to attribute 6 of the 
transaction at node 175. Although this value is equal to the 
binnable parcel post packing standard (which includes marking) , 
it is not meant to indicate that all shipped IPG Is will be 
mailed. It is simply reasonable to assume that a line item 
of binnable material being prepared for shipment would be 
packaged in a manner similar to parcel post. It appears realis- 
tic to assume that line item quantities for IPG Is are not 
excessive and therefore are not subjected to a light pack rate 
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of 0.465 hours. Therefore, with the line item quantities 
small and consolidation ignored, a packing rate similar to 
parcel post seemed appropriate. Once again, if on-site evalua- 
tion indicates that IPG consolidation should be considered, 
the network segment should be modified. Although a batch input 
of IPG Is by a Fleet unit should be rare, it is probable 
that shore customers, particularly Naval Shipyard Long Beach, 
will occasionally originate multiple high priority requests. 

The 80% of the IPG I local delivery material that is routed 
to node 176 is assigned a mark plus pack time of 0.05 hours. 

This value is arbitrary, but allowing three minutes to place 
a small item in a box or envelope and affixing the address 
portion of the DD 1348-1 seems adequate. Having assigned 
the appropriate pack plus mark time to attribute 6 of each 
IPG, the actual time is expended between nodes 177 and 178. 

The packing and marking completed, the resource is freed at 
node 178 and the issue is considered complete with the routing 
of the transaction to Figure 9-4 for the collection of statistics. 

The processing of the lower priority material on the other 
13 packing lines is somewhat more complex. First, parcel post 
line material, which is processed on a line item basis, is 
isolated and routed to node 188 by the probabilistic branching 
from node 182. The branch percentage value of 8% is slightly 
more than the percentage theoretically allotted to any one of 
the other 12 lines. This branching decision is once again 
simply a starting assumption and should be revised in the face 
of evidence to the contrary. As previously mentioned, lotted 
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material for small customers (less than five line items) is 
routed to the parcel post line without sorting . Therefore, 
each item will be processed separately and, despite the fact 
that a majority of the material on this line is slated for 
local delivery, each item will be assigned a parcel post pack 
plus mark time. This approach was adopted to model NSC San 
Diego's current procedure of mailing local delivery material 
to local Fleet customers. Using a special arrangement with 
both local and Naval Station postal authorities, this procedure 
generally leads to a one day delivery time, which represents 
an improvement over the delivery time normally attained through 
the use of the local delivery system. If this practice is 
discontinued, a regular node with probabilistic branching 
should be added prior to node 188 to provide routing to either 
a parcel post packing value assignment or a local delivery time 
standard with a lower value. Theoretically, the revision 
would yield a parcel post line network identical to nodes 174 
through 176 of the IPG I processing segment. 

Material branching from node 182 to the other 12 lines is 
immediately assigned an attribute 6 value of 0.009 hours at 
node 183 to represent the containerization function. Consoli- 
dation will occur whether the material is destined for shipping 
or local delivery. At node 184 the local delivery material is 
segregated and routed to node 185 where a marking time is added 
to the existing attribute 6 value. Therefore, local delivery 
material is not assigned any additional packing time beyond 
the 0.009 hours established at node 183. Since the mark time 
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standard of 0.095 hours applies to one container, the addition 
to each line item at node 185 is factored based on the 7.6 
line items per rough pack assumption. Implicit in the treat- 
ment of local delivery material is the assumption that con- 
solidation is occurring in light pack volume containers . If 
the local delivery material were divided into light and heavy 
rough pack through the inclusion of an additional probabilistic 
branch preceding node 185, the mark time additive for heavy 
rough pack would simply be reduced to half the light pack 
value since twice as many line items are in each heavy pack. 
Incidentally, assigning a full mark time to local delivery 
items is somewhat erroneous; the marking procedure is not as 
complex for local delivery containers. 

The bottom branch from node 184 is taken by material des- 
tined for shipping. The 30% heavy pack branch from node 186 
again has no statistical basis? it's simply a starting point. 
Parcel post, heavy, and light pack percentages for binnable 
material were not readily available. The attribute 6 additions 
at nodes 186 and 201 represent the pack plus mark value des- 
cribed below the nodes. The pack time addition was discussed 
earlier in this section. 

The actual time to pack and mark is expended on the branch 
between nodes 189 and 190, the free node for this network seg- 
ment. The conditional branching from the free node completes 
processing on parcel post items plus the material destined for 
shipping; the parcel post attribute 6 value will equal 0.08 
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and both light pack (0.083) and heavy pack (0.109) will exceed 
the node 190 upper branch lower bound. 

Local delivery material, having an attribute 6 value of 
0.022, will be routed along the lower branch from node 190, 
encounter the indicated two hour delay enroute to local delivery 
staging, and will be probabilistically assigned by node 191 
to one of the eight indicated delivery zone queues. Local 
delivery will be discussed later in this chapter. It suffices 
to note at this point that these queues will be emptied in 
accordance with established delivery schedules. Broadway bulk 
material and National City local delivery material, less pro- 
visions and SERVMART, are also shown entering node 191. The 
direct input to selected zone Q-nodes consists of provisions 
and National City SERVMART material from Figure 9-3. Neither 
of these material categories go to all zones. 

The issue process, and particularly the packing evolution, 
is a lucrative area for analysis through the use of alterna- 
tive modeling schemes. All 13 lines could be modeled indi- 
vidually. More realistically, the large customer SP and LP 
lines might be modeled as a separate entity with two resources 
and a complete heavy pack operation in recognition of customer 
volume. The parcel post line is also a superb candidate for 
distinct resources. As noted in Chapter 8, the remaining 10 
packing lines are basically indistinguishable due to the 
equalized workload principle. However, as the number of 
independent packing lines, and hence the number of distinct 
resource types, increases, provisions must be made for idle 
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resources to be allocated to busy lines; the packers do not 
remain idle if there's work to be done on other lines. The 
example shown earlier in the chapter that described the freeing 
of resources based on an attribute value set equal to the 
resource type could be used to eliminate any possibility of 
idle resources. 

It should be apparent that the branching decisions and 
time assignments made throughout the issue, packing, and mark- 
ing networks are crude at best. Knowledgeable NSC San Diego 
personnel should review and modify any noticeably inaccurate 
times or percentages as part of the pre-simulation validation 
process. If the final model is found to be useful for the 
purposes described in the introduction. It is imperative 
that sufficient data be collected to ultimately prescribe a 
model that approximates reality to the extent that it can 
confidently be used to assess the relative impact of various 
processing alternatives. 

D. NATIONAL CITY MATERIAL PROCESSING 

The National City operation depicted in Figure 9-3 is 
composed entirely of network structures that have been described 
in previous discussions. The resources allocated at nodes 203 
and 210 process the contents of Q-nodes 202, 208, and 209 in 
the same manner as the DPD Keypunch queues on Figure 7-7. IPG 
Is in Q-node 202 are processed exclusively by the type 14 
resources at allocate node 203. Similarly, Q-node 209 provisions 
documents are issued solely by the type 15 resource at allocate 
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node 210. The lotted Q-node 208 National City issue documents, 
which include QUICK PIC and SERVMART requests, may be processed 
by either type resource. It is anticipated that the lower 
volume in Q-node 202 will lead to the majority of the lotted 
material being issued by type 14 resources. Nevertheless, 
personnel devoted to provisions issues will issue lotted 
material from Q-node 208 when node 209 is empty. 

Nodes 213 through 219 model the National City accumulation 
and forwarding of warehouse refusals originated at free nodes 
205 and 212 of the issue processing networks. The messenger 
arriving at node 216 is the National City driver originally 
encountered on Figure 7-6. The operation of the network is 
identical to the warehouse refusal processing at Broadway 
described in conjunction with Figure 9-1. 

Material issues take the 0.99 branches from free nodes 205 
and 212. In the upper issue processing network, IPG I Bearers 
are immediately completed at node 206. QUICK PICs, which 
theoretically reside at the head of Q-node 208 at the beginning 
of each work day, are also extracted from the system at node 
206; the only remaining action on these transactions is the 
delivery to the designated customer pick-up point. The FIFO 
queueing philosophy at node 208 ensures that lotted backlog is 
worked prior to beginning the issue of a new day's documents. 
Therefore, significant backlogs in Q-node 208 may prevent the 
expeditious processing of QUICK PIC issue documents and present 
a distorted picture of actual response time for this specific 
issue category. The standard Q-GERT analysis program output 
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National City Issue and Pack/Mark 





describing Q-node 208 should be closely reviewed in conjunction 
with the QUICK PIC output statistics collected on Figure 9-4 . 
Bearing in mind that approximately a fifth of these transac- 
tions will routinely be delayed over the weekend, an unaccepta- 
bly long QUICK PIC response time, which simply does not occur, 
may be countered through one of the following model revisions: 

(1) Isolate National City QUICK PIC documents with the addition 
of an A3.EQ.3 branch from node 138 on Figure 8-2 and route 
them to Q-node 202 on Figure 9-3 where they will be processed 
directly after IPG Is; or (2) perform the same isolation as 
above but route them to Provisions Q-node 209, which would 
have its ranking designator changed to S/3. A similar analysis 
should be conducted on Q-nodes 143 (bulk) and 148 (bin) on 
Figure 9-1. A remedial action similar to alternative (1) and 
featuring conditional branching of QUICK PICs directly from 
nodes 136 and 137 on Figure 8-2 to IPG I queues 147 and 142, 
respectively, on Figure 9-1 may be instituted if necessary. 
Although the routing of QUICK PICs to the IPG I queues may have 
been the most accurate modeling approach from the outset, the 
technique actually used was deliberately chosen to force an 
initial analysis of standard Q-GERT output for a specific 
material category. It was considered advantageous for the 
understanding of both Q-GERT symbology and standard program 
output to provide a specific analytical starting point for 
which the remedial modeling change, if needed, would be 
relatively minor. 
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Returning to Figure 9-3 at node 206, it should be noted 
that SERVMART transactions are routed to node 222 with a 1.5 
hour delay for distribution to specific delivery zone queues. 
This procedure differs from the treatment given Broadway 
SERVMART material, which was considered complete with routing 
to SERVMART Central Receiving. There is no provisions (A3.EQ.7) 
branching from node 206 because the upper network does not 
process that material category. 

The bottom branch from node 206 routes the remaining mater- 
ial to the local delivery or shipping/packing determination at 
node 207. Local delivery material is branched to node 233 
where IPG Is are completed and the remaining material is de- 
layed 1.5 hours enroute to the full range local delivery zone 
branching at node 191 on Figure 9-2. The conditional branch- 
ing encountered at node 232 for items to be packed segregates 
the IPG I issues, delays them only 0.5 hours vice 1.0 hour 
for lower priorities, and designates the routing to Q-node 
223, the IPG I packing queue. The remaining material to be 
packed is routed along the lower branch from node 232 to pack- 
ing Q-node 224. Note that node 207 also makes the packing 
decision on material issued in the lower network segment; the 
lower branch from node 220 accomplishes the desired routing 
up to node 207. 

The issue processing network using type 15 resources func- 
tions in a similar manner. However, provisions issues, which 
are made only by this resource, must be isolated and routed to 
the appropriate delivery zones. The segregation occurs at node 
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220 and the probabilistic branching to selected delivery zones 
is performed at node 221. The illustrated modeling scheme 
assumes all provisions requests are from local customers and 
the distribution of material issued is basically equal across 
all delivery zones. If these assumptions are erroneous, the 
appropriate network branching must be incorporated into the 
model and the corresponding Q-GERT cards changed accordingly. 

Once material has been routed to Q-nodes 223 and 224, the 
packing queues. National City issues are packed and marked 
using network symbology identical to the Figure 9-1 Broadway 
bulk packing model. The mark standard of 0.095 hours and the 
parcel post 0.1 hour value are the same at both locations, but 
the light and heavy packing times at National City are higher. 
Note that there are three times more pack/mark resources at 
National City (9 type 16) than at Broadway (3 type 11) . In- 
asmuch as there is a significantly larger percentage of light 
and heavy pack accomplished at Broadway, initial simulations 
may lead to both a large backlog in the Broadway packing queue, 
Q-node 163 on 'Figure 9-1, and a significant percentage of time 
idle for type 16 resources at National City. The higher per- 
centages of light and heavy pack at Broadway more than compen- 
sate for the higher pack times at National City. Furthermore, 
the volume entering Broadway will theoretically be higher due 
to the exclusion of provisions from National City packing. 

The Broadway pack type percentages were supplied by the packing 
supervisor. The National City percentages were estimated 
based on the following data regarding pack type manpower 
assignments : 
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4 individuals are assigned to the light pack function 
which requires 0.465 hours per pack 

2 individuals are assigned to the heavy pack function 
which requires 1.43 hours per pack 

2 individuals are assigned to the parcel post function 
which requires 0.1 hours per pack 
Assuming that the individuals assigned accomplish the required 
packing with negligible idleness and with minimal shifting of 
resources across functions, it was inferred that there is 14 
times more parcel post business than heavy pack; the same 
number of people are kept busy performing a function that takes 
approximately 1/14 of the time needed for a heavy pack. Simi- 
larly, the ratio between parcel post and light pack personnel 
assigned and pack times implies that there is approximately 2.3 
times more parcel post volume than light pack. Therefore, a 
ratio of 1:2.3:14 applies for parcel post, light, and heavy 
pack. The indicated percentages on the branches entering nodes 
227 through 229 approximate that ratio, but are suspect in 
view of the corresponding Broadway bulk percentages. There- 
fore, standard Q-GERT output for Q-nodes 163 and 224 and the 
utilization of type 11 and 16 resources should be closely scru- 
tinized. The resource levels and pack type percentages should 
also be reviewed on-site with appropriate packing supervisory 
personnel. If National City packing processes a significant 
input not included in this model, then the indicated resource 
capacity and/or pack percentages are invalid. Furthermore, 
if parcel post packers spend a significant part of their time 
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assisting in the light or heavy pack evolution, an adjustment 
corresponding to their degree of involvement must be made. 
Finally, the packing percentages are also based on the assump- 
tion that only one person is required to pack one line item, 
regardless of the pack type used. A determination that two 
people are used on each heavy and/or light pack would obviously 
alter these percentages . 

E. LOCAL DELIVERY 

The Q-GERT symbology modeling the local delivery system 
consists of the delivery zone queues on Figures 9-2 and the 
allocate node network, nodes 232 through 236, on Figure 9-4. 

The zone percentages emanating from node 191 on Figure 9-2 
were supplied by Production Planning representatives. The 
zone percentages for National City provisions and SERVMART 
material given on Figure 9-3 and shown entering selected Figure 
9-2 delivery zones from nodes 221 and 222 may be categorized 
as strictly arbitrary. Since only 5% of all SERVMART replenish- 
ments are issued from National City, revision of the branching 
proportions from node 222 should have little impact on the 
operation of the model. The provisions percentages should be 
reviewed, however. The equal branching assumption should be 
changed in the event that a higher percentage is routinely 
delivered to particular zones; e.g., if two large customers 
such as MCRD (Marine Corp Recruiting Depot) and NTC (Naval 
Training Center) occupy the same zone, the percentage assigned 
to that zone on Figure 9-3 should be adjusted accordingly. 
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The Figure 9-2 zone queues effectively model the staging 
of material for local customers by delivery zone. At the time 
of this writing, material was being staged strictly by UIC at 
the Broadway complex. Therefore, a significant manpower 
investment dedicated to locating all the material for a par- 
ticular zone was required to determine the transportation re- 
sources needed to effect delivery the following day. The 
rationale for this seemingly inefficient staging method is 
unknown. The cost associated with converting to a UIC within 
delivery zone system apparently has either never been esti- 
mated or found to be prohibitive. If the former is the case, 
it would appear prudent to assess the costs and benefits 
associated with implementing a staging technique that would 
both simplify the determination of the transportation resource 
requirement and reduce the possibility of inadvertently over- 
looking small local customers spread throughout the staging 
area . 

There is a local delivery staging area at both Broadway 
and National City. However, since material from each location 
is delivered on the same schedule to appropriate zones, the 
modeled approach consolidates them into one delivery system. 
The following nine zones, with their respective locations and 
delivery schedules given, comprise the NSC San Diego local 
delivery operation: 
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ZONE 

NUMBER 


LOCATION 


DELIVERY 

SCHEDULE 


1 


PIER 1 


Monday and Thursday 


2 


PIER 2 


Monday and Tuesday 


3 


PIER 3 


Monday and Tuesday 


4 


LONG BEACH 


Daily 


5 


NAVAL STATION 


Monday and Wednesday 


6 


POINT LOMA 


Tuesday and Thursday 


7 


NAS MIRAMAR 


Tuesday and Friday 


8 


NAS NORTH ISLAND 


Monday and Thursday 


9 


NSC SAN DIEGO 
(INTERNAL) AND TENANT 
ACTIVITIES 


Daily 



Although there are nine zones listed above, only eight zone 
queues appear on Figure 9-2. Piers 2 and 3, which share the 
same delivery schedule and the same transportation method 
(usually straddle truck) , were combined into a single delivery 
zone. Pier 1 and NAS North Island, zones 1 and 8, also have 
a common delivery schedule, but require different transporta- 
tion resources to physically move the material. Therefore, 
these zones were modeled as distinct despite their common 
schedule . 

A change to the above zone definitions may have occurred 
before the distribution of this report. Material previously 
designated for zones 1 through 3 above will eventually be 
designated as Naval Station, zone 5, issues. Once implemented, 
this procedural change will restrict the zone designators 
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appearing on DD 1348-1 issue documents to 4 through 9. Piers 
I, 2, and 3 are located at the Naval Station, a factor that 
tends to support a common zone designation. However, the 
delivery schedule for the four affected areas will purportedly 
remain the same. Therefore, the existing modeling approach 
will remain valid despite the revised zone designations. Of 
course, any change in delivery schedules would necessitate 
model revisions. 

Numerous techniques could have been used to account for 
the Transportation Hold Time in local delivery. In fact, if 
each requisition's time in the system were the only factor of 
interest, there would be no need for either the Figure 9-2 
Q-node network or the Figure 9-4 resources to process the Q- 
node contents. Following the zone determination at node 191, 
221, or 222, each transaction could be assessed a delay deter- 
mined by a distinct user function for each zone. The delay 
assigned would be computed as the difference between the next 
scheduled delivery day for that zone and the current day, 
which could be computed from simulation time through the use 
of modulo arithmetic. Having experienced the appropriate 
delay, each transaction would be routed to the statistics 
collection network. This technique was considered inadequate 
for the following reasons: (1) It does not provide illustra- 

tive Q-GERT graphics of local delivery, an exceptionally criti- 
cal requisition processing functional area; (2) it does not 
represent a modeling approach that can readily be modified to 
incorporate either additional complexity or ensuing processing 
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Figure 9-4. Local Delivery and Issue Statistics 








functions; and (3) the FORTRAN background of the model's 
potential users may not be broad enough to include an exposure 
to concepts such as the modulo function. A stated objective 
of the model is to initially minimize both the quantity and 
complexity of FORTRAN program inserts. 

The selected modeling scheme has none of the aforementioned 
objectionable features. It visually portrays each distinguish- 
able zone's staging area as a Figure 9-2 Q-node. The dashed 
line leaving each Q-node terminates at a connector containing 
a list of the Figure 9-4 allocate nodes that process trans- 
actions residing in that queue. There is one allocate node 
for each weekday. Therefore, the ALL designator on the connec- 
tors for Q-nodes 194 (Long Beach) and 170 (NSC San Diego) indi- 
cates that resources are allocated for these queues each day; 
i.e., there are daily deliveries to Long Beach and NSC San 
Diego. Of course, the Figure 9-2 method of indicating routing 
to multiple nodes is not a standard Q-GERT graphical technique. 
Five dashed lines should have been originated at Q-nodes 194 
and 170 and terminated at connectors labeled 232 through 236. 
Space constraints on Figure 9-2 prevented the use of the con- 
ventional graphical method. The appropriate standard routing 
is depicted on Figure 9-4. 

The five dissimilar resource types at allocate nodes 232 
through 236 are controlled from the timing network. The indi- 
cated capacity of 1 for each resource is immediately altered 
to zero. The positive integer initial capacity is necessary 
to avoid a fatal input error, which will inhibit the simulation 
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run. The immediate altering to zero prevents the processing 
of queued transactions until 1000 of the indicated weekday 
when one resource will be provided to empty all queues ser- 
viced by the available resource type. The logic associated 
with the local delivery network is basically identical to the 
ADP resource allocation symbology on Figure 8-2. The only 
notable difference is the frequency of resource availability; 
each ADP resource is provided daily for a specified time inter- 
val while delivery resources are made available once each week 
for a one hour period beginning at 1000. The 0.00005 hour local 
delivery processing rate, which is even faster than the ADP 
rate, was chosen to virtually guarantee that all the material 
in the given day's zones (Q-nodes) will be removed within the 
allotted hour. In addition, transactions arriving during the 
hour that resources are available will be processed if time 
permits. It appears reasonable to assume that material arriving 
prior to the completion of loading for delivery to a particular 
zone would be included in that day's delivery if adequate space 
is available. 

The zone 4 Long Beach queue, which normally contains a 
large volume of higher priority material, will be designated 
the preferred queue at each allocate node. Q-node 170 material 
for NSC San Diego and its tenant activities, which is also 
delivered daily, will be coded as the least preferred queue. 
Special transportation resources are not generally provided 
for this material. Broadway material for this zone is already 
on-site. National City issues are normally included with the 
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shipment of Broadway material receipts that were inappro- 
priately delivered to National City. Using the resource 
freeing techniques described in Section IX. D, nodes 237 through 
241 assign the resource type as attribute 7 of each transaction 
routed through them. The resources may then be freed at the 
single network free node, node 243, and returned to the appro- 
priate allocate node. Issues of local delivery material are 
considered complete after being removed from their respective 
Q-nodes and assessed the negligible 0.00005 hour delay. There- 
fore, the indicated conditional branching is taken from the 
local delivery network free node to the appropriate statistics 
collection network segments described in the next section. 

The local delivery model selected assumes the availability 
of sufficient transportation resources to deliver all staged 
material. However, it could be easily modified to include an 
assessment of transportation requirements at the beginning of 
each work day by evaluating Q-node contents from the timing 
network. The same FORTRAN user function sown in Appendix D 
and used in the messenger routing system would apply. Based 
upon the queue contents, a specific number of the appropriate 
resource type could then be provided and a more realistic pro- 
cessing time assigned between nodes 242 and 243. In fact, the 
network could be retained in its present form with the exception 
of the free node 243 branching and used to provide the daily 
input to a transportation model. A given day's material for 
local delivery could be routed to free node 243 and deter- 
ministically branched to a Q-node that would serve as the input 
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queue for the transportation network. Decisions on required 
transportation resources, both personnel and vehicles, could 
then be made based on the contents of the added queue. Of 
course, the removal of material from local delivery staging 
should be accomplished earlier than 1000, perhaps the day 
before, and some provision to assess the impact of consolida- 
tion would have to be made; the zone queues contain line items 
rather than the actual consolidated material. 

F. STATISTICS COLLECTION 

The remainder of Figure 9-4 is devoted to the collection 
of issue statistics on various material categories. Each node 
with an I designation will automatically provide statistical 
output delineating time in system variables such as the average 
across all simulation runs, the standard deviation of this 
average, and the minimum and maximum times encountered. A 
histogram may also be provided by defining the first cell upper 
limit in Field 7 of the STAtistics node Q-GERT card. The 
card format permits labeling each STA node for ease of output 
identification. The label assigned to each node on Figure 9-4 
is shown in the vicinity of the node. 

Statistics nodes may be inserted throughout the network to 
collect data of interest. Since the STA node input card in- 
cludes provisions for defining the histogram cell width, the 
number of transactions having a current time in system greater 
than some predetermined standard can be displayed in the last 
histogram cell. Furthermore, statistics on transaction time 
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in selected functional areas may readily be obtained through 
the use of mark nodes and STA nodes. The arrival time of the 
transaction assigned on Figure 6-5 or 6-6 need not accompany 
the requisition throughout the model. Including the M desig- 
nator at any regular network node will result in a change of 
the mark time attribute to current simulation time. Therefore, 
if the collection of interval statistics on all transactions 
leaving Customer Services is followed by the assignment of a 
new mark time, the next interval data collected will measure 
the time following transaction departure from Customer Services. 
Of course, this technique would invalidate the use of the 
Figure 9-4 statistics as a measure of total processing time; 
the statistics collected would only measure the time between 
the last marking and issue completion. 

A second method of conveniently determining average trans- 
action time in a particular network segment involves the use 
of the multiple routing feature of deterministic branching. 
Assume that all transactions leaving a specified area are 
routed to a regular node with deterministic branching. Since 
a duplicate of each arriving transaction will be forwarded along 
every branch leaving the node, the requisitions can be routed 
on separate branches to both a statistics node and the next 
processing station without any mark time change. Each set of 
statistics collected in thisraanner represents transaction time 
in the system at that point. Therefore, the time in a particu- 
lar processing area may be computed, or at least inferred, 
from two successive sets of output statistics. 
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As previously mentioned, only the most rudimentary sta- 
tistics collection features are programmed into the initial 
version of the model. The collection of data on the time 
between transactions was accomplished with referrals on 
Figure 7-6 and interval statistics are collected with the 
Figure 9-4 network logic. A practically unlimited degree of 
data collection sophistication may be included in subsequent 
versions through the use of FORTRAN inserts in conjunction 
with the guidance on user collected statistics provided in 
Chapter 9 of reference (a) . 

A node-by-node description of the Figure 9-4 issue statis- 
tics network will not be given. No additional Q-GERT concepts 
are introduced, the symbology used is relatively simple, and 
the material category for which the statistics are being 
collected is shown at the node. 

G. POTENTIAL PROCEDURAL CHANGES 

An evaluation of existing operational methods is constantly 
in process at NSC San Diego. In addition to the analysis of 
existing DPD procedures covered in Chapters 5 and 8, two pro- 
cedural changes presently baing contemplated in the material 
issue process are worthy of note at this juncture. 

First, a change to the existing method of issuing and 
packing Broadway binnables is under consideration. The current 
procedure calls for all bin material to be routed through packing. 
The revised procedure would eliminate approximately 40% of the 
packing local delivery workload by accomplishing the 
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containerization of this material during the pre-packing UIC 
sort discussed in Section IX. C. The consequences of this 
particular type of revision could readily be evaluated using 
this model. A regular node with probabilistic branching could 
be inserted in the bottom branch leaving node 160 on Figure 
9-1. This node would route 60% of all arriving transactions 
to node 171 on Figure 9-2 and redirect 40% to an alternate 
packing queue and network similar to nodes 179, 180, 183, 185, 
and 189 on Figure 9-2. A statistics node should also be added 
after node 189. Supplying one resource at the new packing sta- 
tion and simulating the revised model for a specified time 
period would permit an assessment of both production rate and 
backog at the additional station and the impact of the decreased 
workload on the current packing operation. Therefore, an 
estimate of the personnel reassignments needed, if any, to 
implement the procedure could be deduced from standard Q-GERT 
output for the relevant Q-nodes and statistics nodes. If the 
additional workload were to be assimilated by the issue re- 
source, type 10 on Figure 9-1, the impact could be observed 
by slightly increasing the issue time on 40% of all binnable 
issues . 

The second proposed change involves the application of the 
complete scope of Production Planning capabilities to the issu- 
ing of IPG III binnable material. The procedure, which was 
briefly discussed at the end of Chapter 8, involves a time 
phased release of IPG III material for local customers based 
upon the scheduled delivery date. The program objective was 
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to have the material arrive at the staging area during the 
afternoon preceding delivery. The new initiative goes one 
step further and includes the addition of a conveyor system 
upon which the material will be transported directly to waiting 
delivery vehicles. This procedure would obviously be more 
difficult to model. If the procedure is in effect when the 
second phase of this project begins, the necessary model revi- 
sions should definitely be made. A suggested starting point 
is the Figure 8-2 lotting logic; a zone determination could 
be made on local delivery material with probabilistic branch- 
ing similar to node 191 on Figure 9-2. A variable delay could 
then be assessed for each transaction based on current simula- 
tion time and the next scheduled delivery. Of course, addi- 
tional network logic would also have to be changed. The zone 
staging Q-nodes, for example, would simply not receive any 
IPG III material. 
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X. NETWORK TIMING 



A. TIMING OVERVIEW 

The network timing logic is used to initiate messenger 
runs, apply and remove ADP, local delivery, and personnel 
resources, and change the autodin and POE arrival patterns on 
a daily basis. Numerous modeling approaches could be used 
to provide the exact timing scheme developed in this chapter. 
The most efficient method would place a heavy reliance on 
FORTRAN program inserts. The seclected method was chosen for 
both its simplicity and the ease with which it may be modi- 
fied and/or expanded to provide weekend or midnight shift 
resources . 

There are two basic approaches that may be used to model 
the standard five day work week. If the functions occurring 
each day are identical, the most convenient technique involves 
the modeling of one day’s events and a decision network that 
provides five repetitions of the same sequence of events before 
initiating a weekend delay. If the daily events differ signi- 
ficantly, it becomes less confusing if a representation of the 
entire week is modeled and relevant functions are initiated 
from each specific day. Of course, the former approach uses 
significantly less nodes and represents the ideal technique 
for any approach that is heavily dependent on FORTRAN inserts. 
For example, as each repetition of the standard day's network 
is initiated, a user function could be called to determine 
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which day of the week was commencing and what events must be 
scheduled. Mindful of the objective to minimize program in- 
serts in the initial model, the timing network contains no 
FORTRAN logic. A disjoint network for the entire week is 
provided. However, in an attempt to illustrate both of the 
aforementioned techniques, the initiation of the entire week’s 
schedule of selected events occurs on Monday rather than on 
a daily basis. 

B. WEEKLY MASTER AND RESOURCE INITIALIZATION 

The upper portion of Figure 10-1 contains a source node, 
node 265, and a closed loop of nodes and delays that total 
168 hours or one week. The model itself, and each successive 
week, starts on Monday at 0430, the time indicated on both 
sides of node 266. The time was indicated twice as a reminder 
that transaction time through a regular node is zerop i.e., 
there is no delay at a regular node that requires only one 
transaction to release it. The 0430 start time was chosen to 
correspond to the changing of the autodin daily demand dis- 
tribution. Since autodin referral input usually originates 
at east coast ICPs, it appeared reasonable to program the 
demand pattern change at the beginning of the ICP working day. 

Two regular nodes representing 0430 and 1530 are encoun- 
tered for each day of the week. The routing from nodes 266 
and 267 occurs on Monday and the 61 hour delay initiated on 
Friday at 1530 from node 275 is the weekend delay. Obviously, 
a Saturday shift could easily be added by inserting regular 
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Figure 10 - 1 . Weekly Master, Initialization, and DPD Keypunch Control 







nodes after node 275 to represent specific times and decreasing 
the indicated 61 hour delay accordingly. The 1530 time desig- 
nation was chosen to correspond to the termination of the 
daily eight hour POE input. Since POE input is terminated 
by a nodal modification procedure triggered by the completion 
of specific activities, the 11 hour delays preceding each 1530 
node are assigned activity numbers that are referenced on 
Figure 10-4 . 

Each 0430 node routes two transactions to node 287 on 
Figure 10-2, the personnel resource control network. The 
transaction with the three hour delay arrives at node 287 at 
0730 and sets all personnel resource types to the capacity 
indicated above the allocate nodes displayed in earlier chap- 
ters. The other transaction sent to node 287 is delayed 7.5 
hours and restores the resources at 1200 after their removal 
for a 0.5 hour lunch at 1130. The removal of all resources, 
which is also initiated at each 0430 node, is accomplished 
by the routing to node 303 on Figure 10-2. The seven hour 
delay programs the transaction's arrival at 1130. 

The routing of two transactions to node 287 and one to 
node 303 is common to each 0430 node in the week. However, 
Monday's node has three additional branches that initiate net- 
work segments that provide a full week's scheduling. The 
transaction arriving at node 347 on Figure 10-3 after a 2.5 
hour delay initiates the day shift activities of the Broadway 
Complex messenger and the National City driver. The transac- 
tion routed to node 342 on Figure 10-3 initiates local delivery 
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resource control for the week. Finally, the routing to 
Figure 10-4, node 358, leads to the control of a full week's 
batch processing, QUICK PIC keypunching, and ADP resource 
allocation. 

Node 270, the Wednesday 0430 node, has one unique branch 
to node 285 to provide specific resource control for DPD key- 
punch personnel, resource types 3 and 4 on Figure 7-7. This 
special network segment, which is shown on the bottom, middle 
portion of Figure 10-1, serves to eliminate these resources for 
a 1.5 day period every two weeks to model payday impact. A 
transaction is sent from node 270 to node 285 at 0430 each 
Wednesday. However, node 285 will not be released until two 
transactions have arrived. Therefore, every other Wednesday 
node 285 is released and activities 16 and 17, representing 
delays of 7.25 and 36.25 hours, respectively, are initiated. 
Activity 16 will be completed at 1145 on Wednesday, a time 
during which all resources have been removed for lunch. The 
completion of this activity prompts the modification of nodes 
288, 304, and 320 on Figure 10-2 and inhibits any resource 
changes until activity 17, the 36.25 hour delay completes and 
reinserts those nodes in the network. The completion of 
activity 17 occurs at 1615 on Thursday or 15 minutes after 
the normal removal of DPD keypunch resources on each working 
day. Therefore, DPD keypunch resources, having been removed 
for Wednesday afternoon and Thursday, will be provided once 
again at 0730 on Friday. 



169 



Each 1530 node in the weekly master network has the same 
two branches. First, a transaction is delayed 0.5 hours and 
sent to node 319 on Figure 10-2 to initiate the 1600 shift/ 
resource change. Finally, a transaction is sent to node 353 
on Figure 10-3 to trigger the network that provides second 
shift messenger service for both the Broadway Complex and 
National City. 

To conclude the discussion of Figure 10-1, the branching 
from node 265, a source node, to nodes 303 and 276 must be 
considered. The routing without delay to node 303 on Figure 
10-2, which is normally accessed to remove all personnel re- 
sources for the lunch break, is a one time initialization of 
all personnel resources to zero. If this step were omitted, 
the transaction arriving at node 287 at 0730 from node 266 
would result in twice the defined capacity of each personnel 
resource being available. The RES card for each resource 
contained a capacity field and, in the absence of an altering 
action, that capacity is assumed to exist when the simulation 
commences. Therefore, the altering of resources up to capacity 
that is initiated at node 287 would actually double all re- 
sources that were not initially zeroed. 

The transaction routed from node 265 to node 276 also pro- 
vides an intialization function. It was mentioned in Chapters 
7 and 9 that the ideal initial capacity for ADP and local 
delivery resources would be zero, an assignment that was pro- 
hibited due to the requirement for a positive integer capacity. 
Therefore, these particular resources were defined with a RES 
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card capacity of one, which would iinmediately be reduced to 
the desired zero value and made available when required. The 
network consisting of nodes 276 through 284 simply accomplishes 
the desired reduction to zero for both ADP resources at nodes 
277 through 279 and local delivery daily resources at nodes 
280 through 284. 

The final branch emanating from the source node triggers 
the disjoint timing network beginning with node 369, which 
is above the Figure 10-1 DPD keypunch control segment. Once 
initiated, this segment runs continuously. The completion of 
each activity signifies the end of a shift. Activity 18, 
which completes at 1600, represents the end of the first shift. 
Activities 19 and 20 are completed at 2400 and 0730, respec- 
tively, and model the end of second and third shifts. The 
completion of activities 18 and 19 controls the Figure 7-5 
nodal modification between nodes 48 and 51. Since this simple 
timing network runs continuously, the modification will also 
occur on Saturday and Sunday. With no weekend shifts in this 
version of the model, the Saturday and Sunday node replacements 
neither serve any specific purpose nor introduce any erroneous 
transaction processing. Therefore, it was not considered 
necessary to create a weekend delay simply to inhibit that 
modification. Subsequent modelers should be aware that the 
modification is occurring each day and, if necessary, revise 
the network segment to inhibit or provide a revised modification 
procedure. For example, the Customer Services Saturday and 
Sunday shifts are basically identical to the weekday second 
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shift. Therefore, the indicated modeler action would con- 
sist of retaining node 51 for the entire weekend. 

It should be apparent that the weekly master could easily 
be replaced by a relatively simple daily master. The unique 
networks accessed from node 266 would have to be restructured 
to represent a single day's processing instead of a full week 
and the payday resource impact could be incorporated without 
any FORTRAN program inserts. However, the weekly master is 
considered an excellent starting point for providing a more 
realistic visual display of daily events and for acquiring 
a more thorough understanding of the network segments through 
repetitive referral to the same functional areas. In addition, 
the approach used greatly simplifies the addition of any daily 
uniques or changes in a specific day's event scheduling the 
user may wish to model and evaluate. 

C. PERSONNEL RESOURCE CONTROL 

There are 21 distinct resource types defined in the model 
and 13 of them are personnel resources that must be provided 
and removed in accordance with established working schedules. 

It is recognized that some of these resources, although modeled 
as unique, are actually interchangeable. Nevertheless, the 
initial model does not provide the capability for dissimilar 
resources to process the same transaction types. Earlier chap- 
ters did, however, provide examples of modeling approaches that 
could be used to effect such a processing technique. When the 
model is validated and operating satisfactorily, embellishments 
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can be added to model such procedures as a routine day's end 
backlog evaluation leading to resource shifts and/or the addi- 
tion of a complete shift. 

Figure 10-2 is conceptually very uncomplicated despite 
its excessive number of nodes. Each column of alter nodes 
contains one node for each of the 13 personnel resource types. 
The leftmost column of alter nodes is activated twice each 
day from the 0430 nodes (266 is Monday, 268 is Tuesday, etc.) 
on Figure 10-1 to reinstate the entire capacity of each re- 
source at 0730 and 1200. The lower left partition represents 
the capacity change made to the resource type shown in the 
partition above it. Consequently, it is apparent that the 
middle column of alter nodes, which prompt a capacity change 
that is the negative of the left column, functions to zero 
all resources. This action is originated once only from source 
node 265 then once each day at 1130 from the same Figure 10-1 
nodes that trigger the full capacity increases at nodes 290 
through 302. 

The first two alter nodes in each column are the DPD key- 
punch resources, types 3 and 4, which are removed from the 
network when activity 16 has been completed and caused the 
replacement of nodes 288, 304, and 320 by nodes 289, 305, and 
321, respectively. When node 289 is in the network, there is 
no further routing of transactions arriving at node 288; the 
transactions are subjected to the routing emanating from the 
node that is presently in the circuit and, since node 289 pro- 
vides no further routing, the transaction is destroyed. It 
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Figure 10-2. Personnel Resource Control 




should be noted that both 304 and 320 could have also been 
replaced by node 289 if conserving nodes were an overriding 
factor. In fact, one node could have been used for the entire 
model to receive all transactions and replace all nodes for 
which no further routing was desired. 

The rightmost column of alter nodes is activated from each 
day's 1530 node on Figure 10-1. This network segment provides 
second shift resource control andprovides a description of 
each resource type for the convenience of the reader. Re- 
source types encountering no delay at any point after node 319 
are reduced to a zero capacity at 1600 and remain unaltered 
until 0730 on the next working day. Therefore, resource types 
3, 4, 8, 11, 13, and 15 have no second shift personnel assigned. 
This can be verified by comparing the 1600 resource changes in 
these nodes with the middle column resource zeroing capacity 
changes; they are identical so no resources remain after 1600. 

The lack of a second shift type 11 resource will prohibit the 
packing and marking of Broadway bulk IPG Is destined for shipping 
until the next working day. This approach was deliberate to 
prompt a comparison of IPG I statistics collected on Figure 9-4. 
This factor is mentioned again in Chapter 11. 

Resource types 1 and 12 encounter an eight hour delay be- 
fore arriving at alter nodes 324 and 330, respectively. There- 
fore, the reduction to zero occurs at 2400 and indicates the 
second shift capacity is equal to the day shift capacity of one 
Customer Services edit resource and one IPG I (OP line) packer/ 
marker . 
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Rsources types 9, 10, 14, and 16 undergo a 1600 alteration 
that leaves one of each resource available until the midnight 
zeroing action at nodes 338, 339, 340, and 341. 

Resource type 2, Customer Services keypunch, is reduced 
to one at 1600 at node 325. However, since the entry of trans- 
actions in-process is to be inhibited during the release of 
demands in-process from 1800 to 1830, this second shift re- 
source is removed during that period by alter node 335 and 
reinstated at 1830 by alter node 336. This resource is also 
zeroed at 2400 at node 337. 

Note that different second shift resource schemes, or even 
the addition of a midnight shift, can easily be incorporated 
into the Figure 10-2 logic. A complete third shift could be 
modeled through the addition of a new alter node column with 
capacity increases equal to the desired number of each resource 
type. The capacity cahnge could be initiated after an 8.5 
hour delay from the Figure 10-1 daily 1530 nodes. 

D. LOCAL DELIVERY AND MESSENGER SCHEDULING 

Figure 10-3 contains three distinct network segments 
referenced in the discussion of the weekly master on Figure 
10-1. The upper two segments are each initiated by the arrival 
of a single transaction from node 266, the Monday 0430 node, 
and the lower segment is activated daily from the 1530 nodes. 

The lower network is the second shift messenger control 
logic. It activates two messenger runs per shift to both 
Broadway and National City. For example, a transaction arrives 
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Figure 10-3. Local Delivery and Messenger Control 



at node 353 from node 267 on Monday at 1530. Attribute 1 of 
the transaction is set to zero and a 3.5 hour delay is initiated 
when node 353 is released. The transaction arrives at node 
354 at 1900 where a constant 1 is added to the attribute 1 
value and transactions are routed to nodes 83 and 72 to initiate 
Broadway and National City messenger runs, respectively. The 
complete Broadway run consuming 1.9 hours will be made. Future 
model revisions could provide a more realistic approach by 
concentrating only on the transfer of autodin IPG Is to Customer 
Services (Q-node 5 on Figure 5-5) and IPG I issue documents 
to the appropriate Broadway warehouse area (Q-note 78 on Figure 
7-6) . The second shift messenger timing was modeled indepen- 
dent of the day shift runs to facilitate future revisions. 
Eliminating selected segments of the complete messenger run 
sequence represents a greater challenge than it would appear 
to pose at first glance. A user function that determines 
selected queue contents and then sends an identical number of 
matching transactions to the appropriate match node represents 
one of the more logical approaches. If, in fact, the contents 
of Q-node 25 are routinely taken to DP D on the second shift, 
then no revision is necessary. This situation should be re- 
searched when the model is reviewed with NSC San Diego personnel. 
The National City logic associated with node 72 does not pro- 
vide a run if Q-node 70 is empty. Therefore, no modification 
of that logic should be required. 

Returning to Figure 10-3, the initiation of the 1900 runs 
is followed by the conditional branching evaluation at node 355. 
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Since attribute 1 is one at 1900, the lower branch back to 
node 354, which contains a three hour delay, will be taken. 

The transaction attribute 1 value will be increased to two at 
2200 and a second messenger run will begin. At this time the 
upper branch from node 355 will be taken and no further routing 
will be provided from node 356. 

The network in themiddle of Figure 10-3 models the day 
shift messenger service for the entire week . A transaction 
that has been delayed for 2.5 hours arrives at node 347 at 
0700 each Monday. Both attribute 1, which is incremented with 
each day change, and attribute 2, which is incremented with 
each of the four daily runs, are initially set to zero. At 
node 348, the day of the week is increased by one and an 
immediate check is made at node 349 to determine whether it is 
the sixth day. If it is, the transaction is sent to node 357 
and routed no further; a run with attribute 1 set at six would 
represent a Saturday run, which is not included in this version 
of the model. Note that node 349 is actually extraneous. The 
conditional branches could have been evaluated directly from 
node 348 since attribute assignments are made prior to evalua- 
ting branching conditions. 

If attribute 1 is one through five, the transaction is 
routed to node 350 where the attribute 2 value is increased 
by one at the same time runs are initiated by the transactions 
routed to nodes 72 and 83. Therefore, the fourth and final 
daily run will be initiated at the same time the attribute 
2 value becomes four. There are no delays encountered between 
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node 347 and the arrival of the first transaction at node 83. 



Therefore, the first Broadway messenger run occurs at 0700. 

Due to the one hour delay on the branch from node 350 to 

72, the first National City run occurs at 0800. 

After a run is initiated from node 350, attribute 4 is 
evaluated at node 351. This node is not extraneous? deter- 
ministic branching was mandatory at node 350 for messenger run 
initiation. If attribute 4 is not equal to four, the lower 
branch is taken from node 351 and the incrementing of attri- 
bute 2 plus another messenger run is accomplished two hours 

later. The last of the four daily runs begins at the same 

time attribute 2 is increased to four, which occurs at 1300 
and leads to the transaction taking the upper branch from 
node 351 to 352. The process must begin again at 0700 the 
next working day. Therefore, attribute 2 is reset to zero at 
node 352 and an 18 hour delay is initiated to time the trans- 
action's 0700 arrival at node 348. 

The network initiates four messenger runs for each attribute 
1 value from one to five. This provides 20 runs a week. It 
should be apparent that a similar technique would be used to 
model five repetitions of a daily master if that approach had 
been used in place of the Figure 10-1 weekly network. 

The upper network on Figure 10-3 functions to provide the 
appropriate local delivery resource (type 17 on Monday, 18 on 
Tuesday, etc.) for one hour commencing at 1000 on the appropriate 
day. In this case, however, the resource type is the value 
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that is initialized, incremented each 24 hours, and evaluated 
to determine the end of the week. 

The transaction arriving at node 342 from Figure 10-1 at 
1000 on each Monday is assigned an attribute 1 value of 16, 
which is immediately incremented to 17 at node 343. The type 
resource provided by node 344 and retained for one hour before 
being removed at node 345 is determined by the attribute 1 
value of the arriving transaction. Therefore, a type 17 re- 
source will be provided at 1000 on Monday, removed at 1100 by 
alter node 345, and routed along the lower conditional branch 
where a 23 hour delay will be initiated. Each transaction 
taking the lower branch from node 345 will arrive at node 343 
at 1000 the following day and have its attribute 1 value in- 
creased to equal the required local delivery resource type for 
that day. Since the resource type has been available for the 
specified one hour period when the node 345 branching evalua- 
tion occurs, an attribute 1 value of 21, the Friday local de- 
livery resource type, indicates that the week's local delivery 
routine has been completed. Therefore, when attribute 1 is 
equal to 21, the transaction is routed to node 346 and no 
further. 

E. ADP RESOURCE CONTROL AND BATCH PROCESSING 

The upper portion of Figure 10-4, which is also activated 
once each week from node 266 on Figure 10-1, initiates six 
batch processing runs each work day and also provides ADP 
resource control for the entire week. 
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Figure 10-4. ADP Resource and Demand Pattern Control 





The modeling technique is similar to a combination of the 
two upper network segments on Figure 10-3. The initial attri- 
bute 1 assignment of zero at node 358 is immediately incre- 
mented by one at node 359 where the end-of-week test is made. 
Since attribute 1 is equal to one at the first node 359 branch- 
ing evaluation, the transaction will be routed to node 361 
for the indicated parallel branching to node 369 for batch 
processing and to node 362 for both ADP resource control and 
the release of QUICK PIC transactions waiting in Q-node 37 on 
Figure 7-5. Node 369 of the batch processing network initializes 
the run count, attribute 2, to zero at 0700 and routes the 
transaction to node 370 where the count is immediately incre- 
mented by one and the 0700 batch run is initiated through the 
routing to node 81 on Figure 6-5. The lower branch from 
node 371, with its accompanying three hour delay, will be 
taken until the sixth batch run, which occurs at 2200, is 
initiated. Attribute 2 will equal six at that time, the upper 
branch from node 371 will be taken, and no further batch runs 
will occur until the next transaction is routed to node 369 
from node 361; i.e., at 0700 on the next working day. 

The 11 hour delay on the lower deterministic branch from 
node 361 models the 1800 arrival of the transaction at node 
362. The routing to node 88 on Figure 7-5 triggers the re- 
lease of QUICK PIC transactions in node 37 to either DPD 
(mechanized) or Customer Services keypunch. Since there's no 
time expended between nodes 362 and 363, a type 6 resource is 
also provided at 1800 by alter node 363. It should be clear 
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that node 362 is not actually needed; the routing to node 88 
could have been provided with an additional branch from node 
363. The type 6 resource, the ADP resource that releases' 
in-process transactions and accomplishes the 1800 special 
provisions run, remains available for 0.5 hours until removed 
at node 364. The 6.5 hour delay after node 364 models the 
elapsed time before the application of type 5 resources at 
0100 to provide demand processing of QUICK PIC requisitions 
waiting in Q-node 112 on Figure 8-2. The type 5 resource is 
removed one-half hour later at 0130. Nodes 367 and 368 pro- 
vide the type 5 lotting resources for the two hour period 
between 0300 and 0500. The two hour delay after node 368 
completes the 24 hour period between arrivals at node 359. 

Therefore, the network logic beginning at node 361 will 
provide five successive days of the aforementioned processing 
sequence for each transaction arriving at node 358 from Figure 
7-1. As shown on Figure 10-4, the processing period commences 
at 0700 on each Monday and terminates at 0700 on the following 
Saturday. This approach is not completely accurate. Some 
of the late Friday and early Saturday processing is actually 
conducted late Sunday and early Monday. For example, an 0100 
QUICK PIC run is conducted early on Monday rather than early 
on Saturday. Since the basic model has no weekend shift, the 
total delay is not changed. QUICK PIC transactions simply 
spend the weekend in an issue queue instead of DPD Q-node 112. 
However, if issue resources were made available on Saturday, 
a model revision would be needed to either delay the QUICK PIC 
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issues until Monday or reschedule their demand processing and 
sorting for early Monday. A thorough review of current NSC 
San Diego ADP scheduling should be undertakn during the model 
validation phase. A Saturday warehouse work force appears 
imminent and is probably already operational. If all or most 
of the issues lotted early Saturday are issued over the weekend, 
the inclusion of weekend autodin arrivals, which actually do 
occur, limited weekend batch runs, and an 0300 Monday lotting 
jrogram may also be advisable (along with the aforementioned 
change to the QUICK PIC processing schedule) . One of the more 
convenient features of modeling with a weekly master is the 
ease with which events unqiue to a specific day may be added, 
deleted, or otherwise modified and subsequently displayed with 
representative new or altered network symbology. 

F. AUTODIN AND POE ARRIVAL PATTERNS 

There are a wide variety of modeling techniques that could 
be used to change the daily demand interarrival pattern for 
both autodin and POE input. The autodin interarrival pattern 
created at node 1 on Figure 6-5 is from the uniform distribution 
described in parameter set 1. The parameters for this dis- 
tribution were developed in Chapter 5 and represent the Thursday 
autodin uniform interarrival pattern. Similarly, the Figure 
6-6 node 13 POE interarrival process, which is described in 
parameter set 2, represents an eight hour Thursday demand 
pattern. The parameter set values corresponding to this dis- 
tribution were also computed in Chapter 5. 
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A distinct parameter set must be used to describe each 
day's autodin and POE interarrival process. In retrospect, 
it is unfortunate that parameter set 1 and activity number 1 
were associated with Thursday's demand data. It would have 
been more convenient to have parameter sets 1 through 5 corres- 
pond to autodin interarrivals for Monday through Friday, respec- 
tively. POE interarrivals could then have been described in 
parameter sets 6 through 10. Completed figures were not changed 
simply to provide more conventional numbering schemes. Future 
modelers, however, would be well advised to adopt a more logi- 
cal numbering pattern to avoid any possible confusion. 

The network symbology in the bottom half of Figure 10-4 
replaces the Figures 6-5 and 6-6 segments preceding nodes 2 
and 14, respectively. The Appendix E program listing groups 
all Q-GERT cards pertaining to a particular figure together. 

The cards corresponding to the Figure 10-4 sequential delay 
network, nodes 372 through 377 and all branches leaving these 
nodes, are included with the coding for Figure 6-5. The nodal 
modification network containing "create" nodes 378 through 
380 plus 1 and 381 represent the daily autodin arrival patterns 
and are therefore also listed with the Figure 6-5 cards. The 
lower create node network, which includes node 13 from Figure 
6-6, switches the POE interarrival distribution daily and is 
therefore listed with the POE categorization cards from Figure 
6 - 6 . 

The term create node refers to a node that functions to 
generate transactions until some programmed event such as nodal 
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modification occurs to terminate the cycle. By routing a 
duplicate of each transaction back through an interarrival 
delay to serve as the next input, nodes such as 378 will 
generate transactions indefinitely unless inhibited in some 
manner. The replacement (modification) of node 378 by node 
382 when activity 21 has completed terminates the regenerative 
process . 

Node 372 is a source node and will be released when the 
simulation begins. Unlike source node 265 on Figure 10-1, 
which routes multiple transactions one time and then becomes 
inactive, node 372 is part of the sequential delay network 
containing nodes 373 through 377 and is released each Monday 
at 0430. Therefore, the 24 hour delays designated activities 
21 through 25 are completed at 0430 Tuesday through 0430 
Saturday, respectively. Activity 26, the 48 hour delay between 
nodes 377 and 372, models the weekend period during which no 
demands are generated. 

Nodes 372 through 376 each route the three following trans- 
actions each time they are released: (1) the activation of 

a 24 hour delay; (2) the activation of an interarrival delay 
which, when completed, will trigger 24 consecutive hours of 
autodin input; and (3) the activation of a three hour delay 
before initiating the appropriate day's POE arrivals, which, 
will terminate after eight hours. 

There are significant differences between the autodin and 
POE switching networks. For comparison purposes, consider the 
routing from node 373, which occurs at 0430 each Tuesday. 
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Activity 22, the 24 hour delay commences. When this activity 
completes, the Tuesday autodin arrival process generated by 
node 379 must be terminated. The activity 22 indicator beside 
the dotted line pointing at node 383 implies that node 383 
replaces node 379 when activity 22 is completed. Therefore, 
create node 379 is deactivated at 0430 on Wednesday. Note 
that node 379 will reenter the network (replace 383) when 
activity 21 has been completed. There can be ho doubt that 
activity 21 will complete before the initiating transaction 
arrives at node 379. First, activity 21, which is the delay 
preceding node 373, will be completed at precisley 0430 on 
Tuesday while the arrival of a transaction at create node 379 
from node 373 will be further delayed by an amount equal to 
a sample from the uniform distribution described in parameter 
set 5. Secondly, even if there were no uniform delay between 
nodes 373 and 379, the very existence of node 373 in the net- 
work would ensure that activity 21 completed and node 379 
subsequently reentered the network before a transaction was 
routed from node 373 to 379; although no simulation time is 
expended traversing node 373, the Q-GERT scheduling process 
recognizes transaction arrival at a node and makes all necessary 
network adjustments, including modifications, before routing 
the transaction elsewhere. Thus, even without the uniform delay, 
create node 379 would be in the network when the initiating 
transaction arrived from node 373. 

The preceding points, which may appear to have been belabored, 
were provided to simplify the discussion of the contrasts in 
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the switching network for POE arrivals. The branch from node 
373 to node 388, Tuesday's POE create node, contains a three 
hour delay to inhibit the activation of POE arrivals until 
0730. In this case, the completion of activity 28 results 
in the simultaneous arrival of a transaction at node 388 and 
entry of that same node as the replacement for node 392. The 
question of which event, transaction arrival or the modifica- 
tion, occurs first is obviously relevant. If the arrival 
occurred without the modification, then node 392 would receive 
the transaction and route it no further. Therefore, no POE 
arrivals would be generated. A call to Pritsker and Associates 
yielded an assurance that the modification will occur first. 
However, if simulation statistics indicate no POE input is 
being generated, then the problem can be resolved by inserting 
a regular node in the network after the three hour delay and 
before node 388. A parameter set 6 uniform delay need not 
be included between the new node and node 388, but it is more 
accurate to have one. The transaction arriving at the create 
node not only starts the arrival process, but also represents 
the day's first arrival. Therefore, the first daily autodin 
arrival is always delayed by an amount determined by the appro- 
priate uniform parameter set. The first POE arrival, on the 
other hand, always occurs at 0730. 

The discussion of the Tuesday network segment applies to 
every other day, also. It should be apparent that a Saturday 
and/or Sunday arrival process may readily be inserted by splitting 
the 48 hour delay at activity 26 and adding autodin and/or POE 
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network setments similar to the daily symbology shown on 
Figure 10-4. 

As a final comment on Figure 10-4, activities 11 through 
15, which function to terminate the daily POE arrivals, are 
each 11 hour delays from the Figure 10-1 weekly master. The 
activity completion time is 1530 in each case with activity 
11 representing Monday, activity 12 Tuesday, and so forth. 

Once again, each create node could have been replaced by the 
same inhibiting/terminating node. Distinct nodes to inhibit 
the interarrival process were used solely for graphic clarity. 

The number of alternatives to the selected modeling approach 
are practically unbounded. The Figure 10-4 model, which can 
be easily modified due to being nearly completely disjoint 
from other network segments, was chosen as an alternate to the 
replacement of one create node by another through a process 
called serial nodal modifications. The autodin and POE arrival 
processes could have been modeled in a fashion similar to the 
Figure 10-5 examples shown below. The create node numbers 
are identical to the Figure 10-4 node numbers, but the mark 
function and attribute assignments are omitted and no further 
routing is shown. 

The network segment presented in Figure 10-5 is provided 
for illustrative purposes only. The interarrival parameter 
sets are not shown and the midweek segment of the POE network 
was omitted because it was simply a repetition of the preceding 
nodes . The intent here is to comment on the serial nodal 
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Figure 10-5. Serial Nodal Modification 




modification process, not to provide an operational alternative 
to Figure 10-4. 

The autodin network shown on the left side of Figure 10-5 
would probably function for one week if node 372, the source # 
node, were not adapted to trigger node 378 each week at 0430 
on Monday. Consider the replacement of node 378 by 379. 

When the 24 hour delay that brings node 379 into the network 
is complete, there will probably still be an interarrival 
delay in process at node 378. If this is the case, the delayed 
transaction arriving at node 378 will be transferred to node 
379, which has replaced node 378, and initiate the next day's 
arrival pattern. If the modification and the completion of 
the node 378 interarrival delay occur simultaneously, there 
is no assurance node 379 will ever be triggered. Therefore, 
specific triggers should be provided for each autodin create 
node at 0430 on the appropriate day to guarantee its activation. 
Once the NEW regular node has replaced node 381 at 0430 on 
Saturday, no further arrivals will be generated unless another 
trigger is routed to node 378. Node 378 will replace the NEW 
node at 0430 on Monday, but will not be activated unless 
triggered from node 372 or from some other network segment. 

Using similar logic, an external trigger must be provided 
at each POE create node. Each NEW node's time in the network 
represents the 1530 to 0730 (or weekend) delay during which 
no POE requisitions arrive. When a NEW node is replaced by 
a create node such as node 388, there is no possibility of 
any int'erarrivals in process serving to activate the create 
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node just added. Therefore, the POE switching network shown 
would generate arrivals for the first Monday only if no sub- 
sequent transactions arrived from node 372 or every Monday 
if there were a weekly trigger from node 372 or elsewhere. 

The create node activation problem is surmountable. The 
approach was avoided due to a lack of understanding of the 
description given serial modification on pages 178 and 179 
of reference (a) . This text was exceptionally thorough in 
most cases. The examples are excellent and the concepts were 
generally presented very clearly. However, more specifics 
regarding the effects of nodal modification, both serial and 
simple replacement, would have been helpful. In addition, an 
expanded explanation or definition of the "node released" 
and "activity completed" criteria may have eliminated some 
confusion. The status of a node, released or not released, 
can be used as a branching condition; it is somewhat unclear 
whether a node released once can ever again assume a not re- 
leased status. A similar vagueness surrounds the concept of 
a completed activity; for example, is an activity that is not 
in process categorized as completed? This question is particu- 
larly relevant in nodal modification modeling. 

The most efficient approach to modeling the switching or 
interarrival patterns would rely on FORTRAN program inserts. 

The create node interarrival distribution could be defined as 
a user function, UF, which could be programmed to compute the 
day of the week from simulation time, variable TNOW, and select 
an interarrival time using the parameter set applicable to that 



day. Therefore, only one autodin and one POE create node 
would be needed. This approach is made possible by the 
accessibility of the parameter set matrix through FORTRAN 
program inserts. In accordance with the objective of mini- 
mizing FORTRAN coding, the less efficient but more illustra- 
tive approach was taken once again. 
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XI. SUMMARY AND CONCLUSIONS 



A. MODEL VALIDATION 

This section actually deals with the two distinct pro- 
cesses of verification and validation. Verification of the 
model consists solely of ensuring that it is operational; no 
consideration is given to how realistically it portrays the 
system being modeled. The next few paragraphs cite various 
segments and aspects of the model that should be carefully 
reviewed during the verification process. 

The messenger service described in great detail during 
the discussion of Figure 6-5 should be closely scrutinized. 

This process was developed to overcome the absence of a standard 
Q-GERT capability to release all queued transactions simul- 
taneously. Adding a branch from node 84 on Figure 6-5 to a 
statistics node collecting ’’between” data should indicate 
whether the modeled technique is functioning properly; the 
time between arrivals at node 84 should be zero during the 
queue emptying process and the first cell of the statistics 
node histogram can be defined with a zero upper limit. The 
output "between" statistics should then reveal a preponderance 
of zeroes plus values greater than or equal to two, the mini- 
mum time between messenger runs (day shift) . 

If the technique does not work, the batch node networks 
can be replaced by a resource allocation scheme that may 
either be similar to the ADP processing technique (capacity of 
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1 with an extremely fast processing time) or provide a re- 
source capacity equal to the number of transactions waiting 
to be removed. In the latter case, the Appendix D User Func- 
tion could be modified to alter resources after determining 
queue contents. Neither modification may ever be necessary; 
Pritsker and Associates is currently testing a technique to 
effect the simultaneous movement of all transactions in a 
Q-node and, if successful, Q-GERT may have a messenger capa- 
bility by the time the model is verified. 

A caution was provided regarding the concurrent insertion 
of the Figure 10-4 POE create nodes and the arrival of the 
initiating, and only, transaction at that same node. There- 
fore, this network segment must also be carefully reviewed 
during verification and, if necessary, the compensating revi- 
sions specified in Chapter 10 should be accomplished. 

The COMMON statement in the Appendix D User Function will 
have to be changed to provide the necessary dimensioning for 
the 1,000 node model. The appropriate COMMON block will be 
apparent when the 1,000 node version is installed. If it is 
needed any earlier, Pritsker and Associates can provide it. 

SERVMART transactions were originally assigned an attribute 
3 value of 8 on Figure 6-6. This value was then changed to 
4.5 on Figure 8-2 to ensure SERVMART replenishments were lotted 
first among IPG III requisitions. Although the system will 
operate satisfactorily with this reassignment, it is unnecessary 
and subsequent modelers may wish to simply assign an original 
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attribute 3 value of 4.5 to SERVMARTs on Figure 6-6 and delete 
the Figure 8-2 value assignment. 

Before preceding to the model validation discussion, a 
peculiarity in the use of Q-GERT resources must be mentioned. 
The initial queue capacity of a resource al-ocation network 
Q-node must be zero. Therefore, a simulation can not be com- 
menced with a representative backlog loaded in Q-nodes that 
are serviced by network resources. However, since the time 
to begin statistics collection is defined on input (on the GEN 
card) , the modeler can and should delay the start of statistics 
collection until a time period sufficient to stabilize the 
system has passed. 

The model's validity is determined by the extent to which 
it duplicates the system or situation it was created to repre- 
sent. Validating the model is the process of comparing model 
output with observed system data and resolving the discrepan- 
cies. The following paragraphs contain information that is 
relevant to the validation process. Most of these topics were 
emphasized as potential problem areas in Chapters 5 through 9 
and are reiterated solely for the convenience of the reader. 

The development of the 6.2% demand exception rate, the 
lack of confidence in its accuracy, and the difficulties asso- 
ciated with determining a better estimate were covered in 
Chapter 5. It should prove beneficial to deveease this rate 
in selected simulations and note the impact on the average 
number of transactions in the Customer Services keypunch and 
edit queues on Figure 7-5. Obviously, any research leading 
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to a more accurate estimate of this rate would contribute to 
the model's validity. 

The demand data in Appendix B was taken from Customer 
Services Feeder Reports . Although this source permits the 
isolation of distinct categories such as Special Programs 
and provides a distinction between POE and autodin input, 
the 1144 demand data is undoubtedly more accurate. It would 
appear that some categorization by cog for provisions and 
certain bulk material would be possible. Therefore, con- 
sideration might be given to revising the model to accommodate 
categories that are identifiable on the 1144. This, of course, 
would be a long range goal. 

The model could be improved immensely with more realistic 
standards for activities ranging from editing on Figure 7-5 
to marking on 9-3. Every constant service time that can be 
replaced by a distributional assumption with a variability 
estimate based on observed processing times will contribute 
to the validity of the model. Packing estimates are particu- 
larly illustrative of the necessity for improved standards. 
Recently developed light and heavy pack standards are modeled 
as identical for Broadway bin and National City material and 
higher (more packs per hour) for Broadway bulk; the DIMES 
standards used in reference (b) are judged to be completely 
errroneous. Regardless of which set of standards, DIMES or 
locally developed, are more accurate, the overriding factor 
in packing is the tremendous variability in pack times. Addi- 
tional time and motion studies are probably out of the question. 
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but all service times used in the model should be carefully 
reviewed with the cognizant functional area supervisors. It 
is possible, or perhaps probable, that this initial model 
version contains erroneous processing times due to the modeler's 
misinterpretation of the data provided. In any case, all 
processing times should be confirmed or, if possible, revised 
to include variability estimates. SHORSTAMPS program develop- 
ment, which purports to determine personnel requirements by 
function, may have contained an intermediate time-by-function 
calculation that is well documented and can be used to improve 
the model standards . 

The uniform interarrival assumption for both autodin and 
POE input was born more out of desperation than from any 
exhaustive research. Time of arrival data is not readily 
available and, even if it were, it is hypothesized that the 
data analysis and subsequent goodness of fit testing would 
represent a major project in itself. Nevertheless, a more 
realistic modeling of autodin and/or POE interarrival times 
might very well contribute the most to model validity. 

The processing of both provisions and Special Program 
transactions could be improved by adding the Customer Ser- 
vices edit function. These categories are edited in their own 
special sections and a definite delay, which is smaller for 
provisions documents, is encountered but accounted for in the 
model. It has also been asserted that a significant portion 
of the provisions input arrives via autodin as referrals from 
DPSC; it appears that specified large local customers such as 
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MCRD (Marine Corps Recruiting Depot) submit requisitions 
directly to DPSC. The model could readily be modified to 
recognize this routing and its impact of reducing DPD key- 
punch provisions workload. 

The Special Program IPG II average daily input of 107 
should be closely screened. If it is erroneous, the model 
should be revised. All Special Program transactions are 
assigned lengthy delays on Figure 7-7 to model their pricing 
cycle. Therefore, IPG II requisitions of this type will usually 
exceed the UMMIPS standard significantly. In recognition of 
this fact, statistics on Special Program IPG II and III trans- 
action processing times are collected at nodes 256 (SPROGII) 
and 262 (SPROG3) , respectively, on Figure 9-4. 

The calculation of the National City heavy, light, and 
parcel post percentages shown on Figure 9-3 should be reviewed 
with the packing supervisor and revised if necessary. Chapter 
IX. D provided the rationale for the computation of these per- 
centages. However, the values do not appear representative 
when compared to similar Broadway bulk percentages. Therefore, 
one or more of the assumptions listed in Chapter IX. D are 
probably erroneous . 

Section IX. D also specified the QUICK PIC processing routine 
as an analytical starting point. QUICK PICs are sent to lotted 
material rather than high priority queues . Therefore, QUICK 
PIC issue statistics on Figure 9-4 should be reviewed to 
determine whether the processing of lotted backlog material 
is preventing the actual expeditious issue of QUICK PICs. If 
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it is, QUICK PICs should be routed to the IPG I queues where 
their processing will be ensured. 

Finally, it was noted that no Broadway Bulk packer (Type 
11 resource) was retained on the second shift, a factor that 
may erroneously delay IPG I material destined for shipping. 
Node 251, Broadway bulk IPH I interval statistics for material 
shipped (Figure 9-4), should be closely monitored to determine 
whether a second shift Broadway bulk packer/marker should be 
added to create more accurate IPG I interval times . 

B. SUGGESTED AREAS OF ANALYSIS 

In the process of developing the model and discussing 
current operating procedures with NSC San Diego personnel, 
numerous opportunities for both model expansion and the 
testing of alternative modeling techniques became apparent. 

The following model expansions, many of which were mentioned 
in Chapters 5 through 10, could be accomplished in the future: 

. Technical. 

. Purchase and nonstandard material exception processing 
by the demand exception unit. 

. Shipping. 

. Local delivery resource control . 

SERVMART Central Receiving. 

. Cold storage requisition processing. 

. Packing and preservation. 

. Isolation of the LP and SP packing lines with a higher 
degree of consolidation (large customer lines by definition) . 
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. Determination of resource costs and tradeoffs through 
similar resource type assignments to personnel with identical 
hourly wages and work capabilities. 

. Programming of resource assignments based on a backlog 
analysis (Q-node content check) conducted in a disjoint re- 
source control network. 

. Addition of weekend autodin arrivals and a limited 
Saturday and/or Sunday workforce; e.g., process only IPG IIs 
on the weekend and measure the impact of the response time 
segments . 

In addition, after the model has been validated and is 
simulating the current system satisfactorily, the following 
alternative processing techniques could be modeled and tested: 
The circumventing of the packing lines for approximately 
40% of all binnable material. 

. Elimination of local delivery staging for local delivery 
IPG III material through programming thearrival of material 
by conveyor belt for direct loading on delivery vehicles. 

. The submission of IPG II transactions to the same pro- 
grammed local delivery arrival process. If statistics nodes 
were strategically placed to measure both SSPT (Storage Site 
Processing Time) and THT (Transportation Hold Time), it could 
be determined whether the decrease in THT more than compensated 
for the increased SSPT. 

. Incorporating a bulk material consolidation factor and 
determining whether time was actually being lost due to the 
increased heavy pack workload. 
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. Routing IPG Is through batch processing and directly 
to the warehouse for issue rather than through Customer Ser- 
vices for remote input. 

The aforementioned changes are only a few of the processing 
functions and options that can be modeled and tested once the 
logic of the basic model is mastered. 

C. CONCLUSION 

Since there are no actual simulation runs being made, 
conclusions regarding the advantages of alternative processing 
procedures would be strictly hypothetical. It was noted, how- 
ever, that the IPG II response time problem cited in reference 
(b) still exists. Adopting a common sense approach to the 
analysis, the following factors contribute significantly to 
the continuation of the problem: 

. Special Program IPG II material - if the Customer 
Services Feeder Reports were interpreted correctly, the 
lengthy pricing delay experienced by this significant volume 
(107 per day) would represent a major detrimental impact on 
the IPG II aggregate response time. 

. Local delivery staging procedures - prior methods, 
which are to be changed in conjunction with the programmed 
release of local delivery IPG III material, consisted of 
staging IPG IIs and Ills together by UIC. Therefore, IPG 
IIs lost their identity as higher priority material after 
leaving packing. If the anticipated staging of IPG IIs 



203 



together and by delivery zone becomes a reality, response 
time may improve to some degree. 

. Local delivery schedule - regardless of the action 
taken to resolve the aforementioned detrimental factors, 
it's apparent that the response time on many IPG II issues 
will continue to exceed UMMIPS standards as long as deli- 
veries are limited to twice weekly at many zones. 

The model is completely displayed on Figures 6-5, 6-6, 
7-5, 7-6, 7-7, 8-2, 9-1, 9-2, 9-3, 9-4, 10-1, 10-2, 10-3, 
and 10-4. The most efficient method of reviewing the 
chapters 6 through 10 details is to make a separate set of 
the above figures for ease of reference. It is hoped that 
the considerable detail included, which was necessary to 
describe the Q-GERT concepts, will not hinder the reviewer's 
recognition of the modeling potential provided by this 
language and its unique illustrative feature. 

The contribution of employees from both NSC San Diego 
and Pritsker and Associates toward the development of this 
model cannot be minimized. Their cooperation, knowledge, 
and perhaps most importantly, their patience were vital 
factors in the model formulation. 
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APPENDIX A - Q-GERT Distribution and Function Types with Required 
Parameter Values 



Distribution 


and Function Types 




Parameter 


Values* 




Code 


Key 


1 


2 


3 


4 


AT 


Attribute 


- 


- 


- 


- 


BE 


Beta 


4 


a 


b 


a 


BP 


Beta PERT 


m 


a 


b 


- 


CO 


Constant 


4 


- 


- 


- 


ER 


Erlang 


u/k 


a 


b 


k 


EX 


Exponential 


4 


a 


b 


- 


GA 


Gamma 


u 


a 


b 


a 


IN 


Incremental 


- 


- 


- 


- 


LO 


Lognormal 


4 


a 


b 


a 


NO 


Normal 


4 


a 


b 


a 


PO 


Poisson 


4-a 


a 


b 


- 


TR 


Triangular 


m 


a 


b 


- 


UF 


User Function 


- 


- 


- 


- 


UN 


Uniform 


- 


a 


b 


- 



* — ^ not used; 4 -^mean; G ^.standard deviatior 
m — ^ mode; a — ^minimum or optimistic time; 
b maximum or pessimistic time. 



205 



APPENDIX B - NSC San Diego Daily Demand Data - October 1979 Through February 1980 
Monday - 18 observations which include Saturday and Sunday input 



A. 


Autodin Input 












4,847 IPG I + 


13,649 IPG II + 


15,137 


IPG III 


= 33,453 TOTAL 


Max 


456 


u 2,174 




2,001 




Min 


40 


228 




367 




Avg 


269 


> 748 




841 


1,858 Avg 


Std . 


Deviation 118.38 


465.25 




428 


Daily Autodin 


% of 


Total 14.5% 


40.2% 




45.3% 


Input 


B. 4- 


— Hot Line (Customer Services) Input 










3,640 IPG I + 


37,984 IPG II + 


27,438 


IPG III 


= 69,062 


Max 


441 


3,198 




2,904 




Min 


51 


728 




440 


3,836 Avg 


Avg 


202 


2,110 




1,524 


Daily Hot Line 


Std. 


Deviation 105.34 


777.6 




544.9 


Input 


% of 


Total 5.3% 


55.0% 




39.7 % 




C.«- 


Provisions Input 
















12,337 


IPG III 


= 12,337 Total 


Max 

Min 








1,558 

216 


685 Avg Daily 


Avg 








685 


Provisions Inpi 


D. <r- 


— -Monday Totals 












8,487 IPG I + 


51,453 IPG II + 


54,912 


IPG III 


= 114,852 


Avg 


471 


2,858 




3,052 


6,381 Demands 


% of 


Total 7.4% 


44.8% 




47.8% 


Per Day 



Provisions input represents 10.7% of all demands and 22.5% of IPG III demand. 
Autodin represents 29.1% of average daily demand for Monday. 

Autodin represents 32.6% of average daily nonprovisions demand. 



IS A 14 January autodin IPG II input of 8,552 was disregarded and replaced with 
the average of the remaining 17 observations. 
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Tuesday - 20 observations 
A. Autodin Input 





6,587 IPG I + 13,082 


IPG II + 12,165 


IPG III = 


31,834 TOTAL 


Max 


622 


1,501 


1,035 




Min 


u 140 


173 


112 


1,592 Avg 


Daily Avg 


1 / 329 


655 


608 


Daily Autodin 


Std. Deviation 132.05 


286.5 


235.88 


Input 


% of Total 


20.7% 


41.1% 


38.2% 




B. Hot Line (Customer Service) Input 








3,667 IPG I + 37,288 


IPG II + 23,480 


IPG III = 


64,435 TOTAL 


Max 


469 


3,476 


2,822 




Min 


44 


1,032 


197 


3,222 Avg 


Daily Avg 


183 


1,865 


1,174 


Daily Hot Line 


Std. Deviation 95.5 


764.7 


637.16 


Input 


% of Total 


5.7% 


57.9% 


36.4% 




C. Provisions Input 












9,979 


IPG III = 


9,979 TOTAL 


Max 






1,457 


525 Avg 


Min 






216 


Daily Provisions 


Daily Avg 






525 


Input 


D. Tuesday Totals 










10,254 IPG I + 50,370 


IPG II + 45,624 IPG III = 


= 106,248 


Daily Avg 


526 


2,519 


2,281 


5,326 Demands 


% of Total 


9.65% 


47.4% 


42.95% 


Per Day 


Provisions 


input represents 9.4% of 


all demands and 21.9% of 


IPG III demand. 



Autodin represents 30.0% of average daily demand for Tuesday. 
Autodin represents 33.1% of average daily nonprovisions demand. 



Is A zero ("0") IPG I autodin input was replaced by the average of the 19 
other values. 
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Wednesday - 21 observations 



A. Autodin Input 



6,322 IPG I + 13,178 IPG II + 16,551 IPG III 



36,051 TOTAL 



Max 


826 


1,376 


1,939 


Min 


25 


159 


268 


Daily Avg 


301 


628 


788 


Std. Deviation 


221.4 


284.2 


431.9 


% of Total 


17.5% 


36.5% 


46.0% 



1,717 Avg 
Daily Autodin 
Input 



B. Hot Line (Customer Service) Input 

3,215 IPG I + 37,902 IPG II + 27,331 IPG III = 68,448 TOTAL 



Max 


392 


3,342 


2,397 




Min 


56 


282 


269 


3,259 Avg 


Daily Avg 


153 


1,805 


1,301 


Daily Hot Line 


Std. Deviation 


85.8 


728.3 


536.1 


Input 


% of Total 


4.7% 


55.3% 


40.0% 





C. Provisions Input 




7,965 IPG III = 


7,965 TOTAL 


Max 


944 


379 Avg 


Min 


132 


Daily Provisions 


Daily Avg 


379 


Input 


D. Wednesday Totals 


9,537 IPG I + 51,080 


IPG II + 51,847 IPG III = 


112,464 


Daily Avg 454 


2,432 2,469 


5,355 Demands 


% of Total 8.5% 


45.4% 46.1% 


Per Day 



Provisions input represents 7.1% of all demands and 15.4% of IPG III demand. 
Autodin represents 32.0% of average daily demand for Wednesday. 

Autodin represents 34.5% of average daily nonprovisions demand. 
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Thursday - 20 observations 



A. Autodin Input 



6,134 IPG I + 15,650 IPG II + 14,794 IPG III 



36,578 TOTAL 



Max 


505 


2,009 


1,176 




Min 


60 


335 


395 


1,829 Avg 


Daily Avg 


307 


783 


740 


Daily Autodin 


Std. Deviation 


120.62 


445.37 


243.27 


Input 


% of Total 


16.8% 


42.8% 


40.4% 





B. Hot Line 


(Customer Service) 


Input 










3,051 IPG I + 31,377 IPG II + 16,590 


IPG III = 


51,018 


TOTAL 


Max 


303 


3,834 


2,906 






Min 


62 


769 


201 


2,551 


Avg 


Daily Avg 


153 


1,569 


830 


Daily 


Hot Line 


Std. Deviation 76.47 


763.77 


339.9 


Input 




% of Total 


6.0% 


61.5% 


32.5% 





C. Provisions Input 








10,987 IPG III 


= 10,987 TOTAL 


Max 


1,069 


550 Avg 


Min 


216 


Daily Provisions 


Daily Avg 


550 


Input 



D. Thursday Totals 



9,185 IPG I + 47,027 IPG II + 42,371 IPG III = 98,583 



Daily Avg 


459 


2,351 


2,119 


4,929 Demands 


% of Total 


9.3% 


47.7% 


43.0% 


Per Day 



Provisions input represents 11.1% of all demands and 25.9% of IPG III demands. 
Autodin represents 37.1% of average daily demand for Thursday. 

Autodin represents 41.8% of average daily nonprovisions demand. 



209 



Friday - 22 Observations 
A. Autodin Input 



8,215 IPG 


I + 14,568 


IPG II + 16,051 


IPG III = 38,834 Total 


Max 


741 


1,331 


1,227 


Min 


24 


320 


238 


Daily Avg 


373 


662 


730 1,765 Avg 

Daily Autodin 


Std. Deviation 


189.1 


251.3 


266.1 Input 


% of Total 


21.2% 


37.5% 


41.3% 



B. Hot Line (Customer Services) Input 

3,978 IPG I + 34,315 IPG II + 23,021 IPG III = 61,314 Total 



Max 




352 


2,662 




2,911 




Min 




45 


661 




225 




Daily Avg 




181 


1,560 




1,046 


2,787 Avg 
Daily Hot Line 


Std. Deviation 




75.75 


556.4 




690.9 


Input 


% of Total 




6.5% 


56.0% 




37.5% 




C. Provisions 


Input 




12,862 


IPG 


III = 12,862 


Total 


Max 










1,687 




Min 










216 


585 Avg 

Daily Provisions 


Daily Avg 










585 


Input 


D. Friday Totals 












12,193 


IPG I 


+ 48,883 


IPG 11+51. 


,934 


IPG III = 113 


,010 


Daily Avg 




554 


2,222 




2,360 


5,136 Demands 


% of Total 




10.8% 


43.3% 




45.9% 


Per Day 



Provisions input represents 11.4% of all demands and 24.8% of IPG III demands. 
Autodin represents 34.4% of average daily demand for Friday. 

Autodin represents 38.8% of average daily nonprovisions demand. 
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APPENDIX C - Data Processing Department Keypunch Statistics 



SPECIAL PROCRAMS 


tf/hr (rounded) 
Avg hr /document 




















169 

.0059 


158 

.0063 


j 158 

.0063 


103 

.0097 


181 

.0055 


153.8 

.0067 


Not 

Established 


Hours 

(Rounded) 




















21 


20 


25 


28 


33 


25.4 hr/ 
month 




Quantity 




















3,546 


<J\ 

m 

C-I 


3,945 


2,877 


5.985 


3,898/ 

month. 


DD 1348 


It f hr (rounded) 
Avg hr/docuuient 


139 

.0072 


138 

.0073 


<r «*» 

<~i o 

Cl 


146 

.0069 


142 

.0070 


138 

.0072 


145 

.0069 


144 

.0070 


154 

.0065 


149 

.0067 


00 

00 ("• 
CM O 

rH O 


132 

.0076 


ON 
sr o 
<3- c 
c 


138 

.0073 


140.4 

.0071 


150 

.00667 


Hours 

(Rounded) 




cn 

CM 


s 


274 


286 


200 


235 


183 


39 




220 


156 


210 


231 


209.1 hr/ 
month 


Punch and 
verify — ^ 


Quantity 


37,987 


32,186 


28,353 


39,882 


40,676 


27,588 


34.177 


26.363 


6,036 


25,862 


28,222 


20,570 


30.208 


31.858 


29,283/ 

month 


PROVISIONS 


If/hr (rounded) 
Avg hr/document 


336 

.0030 


378 

.0026 


284 

.0035 


353 

.0028 


265 

.0037 


00 
fn 
nO O 
O 


262 

.0038 


321 

.0031 


335 

.0030 


385 

.0026 


278 

.0036 


370 

.0027 


306 

.0033 


349 

.0029 


315.3 

.0032 


350 

.00286 


Hours 

(Rounded) 


99 




52 


50 


19 


65 


09 


tn 

<r 


11 


o 

sr 


53 




09 


CM 


49.35 hr/ 
month 


Punch and 
verify — ^ 


Quantity 


22,153 


17,033 


i-> 

no 


17.630 


16.194 


17,196 


15.741 


o 

MT 


3.690 


15.058 


00 


15.053 


18.389 


14.668 


15,489/ 

month 


1 CATEGORY 1 


MONTH 

1979-80 


JANUARY 


FEBRUARY 


MARCH 


APRIL 


MAY 


JUNE 


JULY 


AUGUST 


SEPTEMBER 


OCTOBER 


NOVEMBER 


DECEMBER 


JANUARY 


FEBRUARY 


AVERACE 


STANDARD 
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APPENDIX D - Model FORTRAN User Functions 



FUNCTION UF (TFN) 

}J COMMON/QVAR/NDE, NFTBU (100), NREL (100), NRELP (100), NFJEL2 (100), 
INRUN, NRUNS , NTC (100), PARAM (100,4), TBEG, TKNOW 



UF = -NREL (INF) 



RETURN 



END 



The statement UF * - NREL(INF) indicates that the value returned to the model 
is the negative of the number of transactions in 0-node INF. Therefore, if 
UF 43 were used in the network logic, the value returned would be minus the 
number of transactions in Q-node 43, the Customer Services keypunch queue on 
Figure 6-5. 



JL_/ The COMMON statement applies for the 100 node model as indicated by the 
dimensioning of the various matrices. When the 1,000 node model is oper- 
ational, this COMMON statement will have to be revised accordingly. 
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